> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Jari Arkko > Sent: Monday, December 28, 2009 1:34 AM > To: Seiichi Kawamura > Cc: draft-ietf-6man-text-addr-representat...@tools.ietf.org; > IETF IPv6 Mailing List > Subject: Re: AD review of draft-ietf-6man-text-addr-representation > > Seiichi, > > > I will make the changes. What you pointed out if pretty clear, > > and I agree. > > > > > Thanks. > > >> Sections 5 and 6 are not as strict with respect to > recommending a single > >> choice as would perhaps be desirable. Is there a reason > why the second > >> alternative in Section 5 can't be removed and the RFC 3986 > format be > >> chosen as mandatory in Section 6? For Section 5 I thought that was > >> actually what we had discussed on the list. In other words, change: > >> OLD: > >> For these addresses, mixed notation is recommended if either of the > >> below conditions are met. > >> > >> (1) The address can be distinguished as having IPv4 > addresses embedded > >> in the lower 32 bits solely from the address field. (e.g. > Well Known > >> Prefixes) > >> > >> (2) An external mechanism such as prefix learning or > pre-configuration > >> helps in recognizing the address as having IPv4 addresses > embedded in > >> the lower 32 bits. > >> NEW: > >> For these addresses, mixed notation is recommended if the following > >> condition is met: The address can be distinguished as having IPv4 > >> addresses embedded in the lower 32 bits solely from the > address field > >> through the use of a well known prefix [RFC 4291]. Note that this > >> prevents the use of the mixed notation on some addresses > that employ a > >> dynamically chosen prefix. However, it was felt that the > benefits of > >> deterministic text representation outweigh the benefits of human > >> readability in this case. > >> > > > > The original text was close to what you mentioned. > > The second point was brought up with a request from the BEHAVE WG. > > Removing this would not stop anyone from requiring the mixed style > > for representation in a given protocol, but the other hand, if this > > was mentioned here it would provide a pointer to something that > > should be considered. > > > > I understand their motivations, given that BEHAVE may > introduce new well > known prefixes for translation purposes. > > However, the motivation does not help remove the problem > associated with > dynamically changing formats. An "external mechanism" may be > available > on my host's IP layer but is unlikely to exist in my management > application or the excel sheet that I use to register my addresses. > Every time you introduce flexibility to the address format you risk > making two different parties arrive at a different representation. > > We have the following alternatives: > > 1) Mandate that the text representation is <SOMETHING> and > never changes > after this. It doesn't change even if new WKPs are assigned. This > alternative has the highest likelihood of enabling > comparisons, and the > smallest likelihood of producing readable IP addresses for mixed > IPv6/IPv4 addressing. > > 2) Mandate that the text representation is <SOMETHING> but take into > account new WKPs. Here we can have a situation where an updated node > produces a different string than an older node, if the older > node does > not recognize a new WKP. There's still a reasonable likelihood that > eventually the situation will be corrected, and for most of the time, > readable IPv6/IPv4 addressing can be achieved. > > 3) Mandate that the text representation is <SOMETHING> but > require that > external mechanisms help recognize even dynamically assigned > IPv4/IPv6 > prefixes. This has the highest likelihood of producing readable > addresses, but relies on the existence and proper use of the external > mechanisms.
For (3), I would like to encourage tools to support something like "--prefix=", for example: tcpdump --64prefix=ABCD::/96 which helps reduce the worry that a tool might not know of a WKP (due to release cycles of the new code), and also means a network- specific prefix could also be provided to the tool. -d > 4) As above, but specify a mandatory external mechanism. > > Basically, the choice comes down to how important we believe readable > addresses are in the BEHAVE translation cases vs. likelihood of > achieving proper comparisons. My take is that alternative #2 is a > practical approach with a very high likelihood of working correctly. > > What do other people in the WG think? > > >> The [] style as expressed in [RFC3986] is recommended. > Other styles are > >> acceptable when cross-platform portability does not become > an issue. > >> NEW: > >> The [] style as expressed in [RFC3986] should be employed, > and is the > >> default format unless otherwise specified. Other styles > are acceptable > >> when there is exactly one style for the given context. For > instance, a > >> given protocol specification might indicate that the '#' > format is used. > >> > > > > A discussion early in the draft showed that various implementations > > of a given protocol already had different styles and if > they did not mix, > > we could live with them. I think the following would work, a mix > > of the OLD and NEW. > > > > "The [] style as expressed in [RFC3986] should be employed, > and is the default format > > unless otherwise specified. Other styles are acceptable > when there is exactly one style > > for the given context and cross-platform portability does > not become an issue." > > > > I'm fine with this. > > >> Is there reason why we can't simply recommend the > specified algorithm to > >> be followed for prefixes as well? > >> > > > > Its written in Appendix B. but if you wanted it placed > inside the main > > text, that's not a problem for me. > > > > Yes, please move it to the main text. > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
