> -----Original Message----- > From: Jari Arkko [mailto:[email protected]] > Sent: Tuesday, January 05, 2010 2:39 PM > To: Dan Wing > Cc: 'Seiichi Kawamura'; > [email protected]; > 'IETF IPv6 Mailing List' > Subject: Re: AD review of draft-ietf-6man-text-addr-representation > > Dan, Seiichi, > > > Perfect. > > > > Good, but I don't think we're done. I still need more people > commenting > on the trade-offs between the different approaches (my mail from Dec > 28th). Dan, you commented on the approach #3 and how tool options can > make it more practical. But you didn't explicitly say which > approach you > prefer. Is your preference #3, and if so, why?
Your email from January 28: http://www.ietf.org/mail-archive/web/ipv6/current/msg11215.html, summarized: 1) Mandate that the text representation is <SOMETHING> and never changes after this. 2) Mandate that the text representation is <SOMETHING> but take into account new WKPs. 3) Mandate that the text representation is <SOMETHING> but require that external mechanisms help recognize even dynamically assigned IPv4/IPv6 prefixes. 4) As above, but specify a mandatory external mechanism. Yes, my preference is #3. We have #1 today, which is the ::ffff/96 prefix. We know that BEHAVE is creating two new prefixes: 1. an IANA-assigned Well-Known Prefix. This is fixed and could be hardcoded into software) which is your #2. 2. a network-specific prefix. This is variable, and will be a different prefix on every network. This can be supported by your #3. Regarding your #4, I do not believe we are ready to specify a mandatory way to learn a network translator's prefix. And I say that as author of draft-wing-behave-learn-prefix (which proposes using DHCPv6 and DNS) and my awareness of draft-bcx-behave-learn-address (which proposes using IPv6 RAs). Furthermore, analysis of a network trace (e.g., using tcpdump) might be performed on a different network anyway, so learning the prefix of *my* network's NAT64 isn't helpful; I need to tell my tool the prefix of the NAT64 that was being used when the network trace was collected (example: a customer of Cisco's sends us a network trace, and we need to analyze it. The tool would need to be told the customer's NAT64 prefix (which could be the WKP or their NSP) not Cisco's NAT64 prefix (which could be the WKP or our NSP). Hope that helps. -d -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
