Subject: RE: AD review of draft-ietf-6man-text-addr-representation

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Jan 2010 21:59:19 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Monday, December 28, 2009 1:34 AM
> To: Seiichi Kawamura
> Cc: [email-masked]; 
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Seiichi Kawamura <[email-masked]>
Date: Tue, 05 Jan 2010 18:33:00 +0900

Jari, Dan

Happy new year.

I'm going with Jari's text,
and I'm adding a little to the next paragraph
(which talks about exceptions)

         <t>There will be situations where certain prefixes that do not meet this
condition will prefer a mixed notation to meet certain needs. On the other hand, there may
be situations where conditions are met, but full hexadecimal representation is chosen.
Addressing these needs is out of the scope of this document. Tools that provide options to
specify prefixes that is (or is not) to be represented as mixed notation may be useful in
these cases.</t>

Regards,
Seiichi

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 07:36:42 -0800

> From: Seiichi Kawamura [mailto:[email-masked]] 
> Sent: Tuesday, January 05, 2010 1:33 AM
> To: Dan Wing
> Cc: 'Jari Arkko'; 
> [email-masked]; 
> 'IETF IPv6 Mailing List'
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jari, Dan
> 
> Happy new year.
> 

Perfect.  

Thanks!
-d

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAktDB0wACgkQcrhTYfxyMkJp4QCfQcDJeAXrkmMZZUpk4nOLqDd2
> ocMAnjToOyPD9lC0cKr1zhCTeM4DPa6K
> =0LPT
> -----END PGP SIGNATURE-----

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Jan 2010 23:39:23 +0100

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?

Jari

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jan 2010 14:50:51 -0800

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, January 05, 2010 2:39 PM
> To: Dan Wing
> Cc: 'Seiichi Kawamura'; 

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. 

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

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 Jan 2010 11:37:52 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dan Wing
> 发送时间: 2010年1月6日 6:51
> 收件人: 'Jari Arkko'
> 抄送: [email-masked]; 'IETF IPv6
> Mailing List'
> 主题: RE: AD review of draft-ietf-6man-text-addr-representation
> 
> 
> 
> Regarding your #4, I do not believe we are ready to specify a mandatory
way
> to

If my memory is correct, using IPv6 RA for prefix64-learning was initially
proposed in [I-D.wing-behave-learn-prefix]. However, it was removed from the
-04 version of that draft.

[I-D.wing-behave-learn-prefix]
              Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix
              of an IPv6/IPv4 Translator",
              draft-wing-behave-learn-prefix-02 (work in progress),
              May 2009.
Xiaohu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jan 2010 08:07:55 +0100

>    4) As above, but specify a mandatory external mechanism.

My main interest is textual comparability of addresses coming from
potentially many different sources. If I can compare addresses safely
only if I know some context information communicated out of band or I
have to configure all sources to produce the same, I feel somewhat
uneasy. My preference thus is 1), I might be OK with 2) if the
frequency of the introduction of new WKPs is very small.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jan 2010 08:35:21 -0800

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, January 05, 2010 11:08 PM
> To: Dan Wing
> Cc: 'Jari Arkko'; 

BEHAVE is introducing both (1) a WKP which embeds the IPv4 address
in the last 32 bits and (2) allowing networks to use their own 96-bit
prefix and embed the IPv4 address in the last 32 bits.

Your proposal would prohibit (2) from displaying the IPv4 address in
dotted decimal, because of a fear the parsed IPv6 address might be
seen or used on another network.  

Personally, I find this useful.  If I'm on my home network and somebody
sends me a trace with their IPv6 prefix and some dotted-decimal displayed
in the last 32 bits, I know immediately that their tool (running on their
network) believed -- through whatever means -- that the last 32 bits
was an IPv4 address.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jan 2010 08:39:23 -0800

> > 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).
> 

Using Router Advertisements was added in -02 (using text from
draft-bcx-behave-learn-address) , and removed in -04.  It was removed because
feedback I received was that we should build a mechanism to send DHCP messages
in Router Advertisements, rather than trying to specify half a dozen documents
which effectively duplicate DHCP options in RAs.  I thought an editing team
was starting to work on such a document (to standardize how to send DHCP in
RAs), and pinged two of the authors just yesterday, but I haven't heard back.

-d

> > 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
> > would need to be told the customer's NAT64 prefix (which 
> could be the WKP
> or

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2010 01:21:14 +0100

> network) believed -- through whatever means -- that the last 32 bits

My concern are tools/applications generating different textual
representations of the same addresses because of different contextual
information they have. This then requires smart tools that can
normalize things in order to make comparisons easy.  Avoiding the need
of special tools to enable comparisons of IPv6 addresses I think was
one of the motivations behind this work.

/js

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 07 Jan 2010 09:26:19 +0900

I guess it comes down to either (2) or (3),
but I'm slightly uncomfortable with the word "require" in (3).

What I personally like, is

the text representation is <SOMETHING>, take into account new WKPs.
Also suggest that tools might help if they had the option to
recognize even dynamically assigned IPv4/IPv6 prefixes.

So my bid would be (2), but add a little more on
how tools might become more useful in some cases.

Regards,
Seiichi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Jan 2010 15:18:43 +1300

> one of the motivations behind this work.

Surely we can never hope to eliminate the need for converting to a
a canonical form before comparing. The canonical form for machine
comparisons is fairly obvious - a 128 bit binary number. The question
seems to be whether we can define a canonical form for eyeball comparisons.

I thought the idea of this work was to help humans by minimising the
variability in the "printed" version of an address. Showing an embedded
IPv4 address in dotted decimal is part of that, but it's only going to
happen when the source knows algorithmically that it *is* an IPv4 address.
I think we have to accept that this is not always the case, and that
there will inevitably be cases where two sources of a text representation
of the same address present different results, because one source has
contextual information that the other doesn't.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Jan 2010 08:30:39 +0200 (EET)

> frequency of the introduction of new WKPs is very small.

While I like to see v4 address in a readable form when its used that 
way, I have to say I agree with Jürgen's concerns, especially if the 
algorithm was applied to opertor-specific prefixes as well (the tool 
would have to have this OOB intelligence).

However, in some cases I'm not sure if comparison equality is really 
such a big deal.  I don't think there's a way to satisfy both 
"embedded v4 readability" and "absolute comparability" so a tradeoff 
must be made.

So, I'd actually suggest that we go for 1) or 2) but soften that a 
bit, like: "if it is known by some external method that the prefix 
includes an IPv4 address, the representation MAY print it in dotted 
decimal". With "external method" I'm thinking of either a command-line 
argument or application's own logic; I don't see how you could get 
that information "dynamically" so that it would be available to 
applications (for example, I don't see apps like that using DHCP 
information..).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jan 2010 22:36:12 -0800

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Wednesday, January 06, 2010 10:31 PM
> To: Juergen Schoenwaelder
> Cc: Dan Wing; 

Works for me.

-d

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2010 08:48:43 +0100

> variability in the "printed" version of an address.

The motivation is not just eyeball comparison by humans as explained
in section 3 of the ID. IP addresses are stored in many places in a
textual form where the options of automated search and comparison are
textual and conversion to a 128-bit binary number for comparison is
often not a realistic option. Section 3 of the ID discusses some
examples.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Jan 2010 08:21:34 +1300

> often not a realistic option. Section 3 of the ID discusses some

Well, any attempt to make arbitrary text comparisons 100% reliable is
logically excluded by the first paragraph of section 4.

For reliable text-to-text comparisons you have no choice but to
convert to a strict canonical form, and that surely means converting
dotted decimal to hex, if you can't convert to binary.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Jan 2010 08:26:26 +1300

On 2010-01-07 19:30, Pekka Savola wrote:
> such a big deal.  I don't think there's a way to satisfy both "embedded
> v4 readability" and "absolute comparability" so a tradeoff must be made.
> 
> So, I'd actually suggest that we go for 1) or 2) but soften that a bit,
> like: "if it is known by some external method that the prefix includes
> an IPv4 address, the representation MAY print it in dotted decimal".
> With "external method" I'm thinking of either a command-line argument or
> application's own logic; I don't see how you could get that information
> "dynamically" so that it would be available to applications (for
> example, I don't see apps like that using DHCP information..).

Exactly. After all, this whole document is only a recommendation,
with strict backwards compatibility with the flexible format.

    Brian

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Jan 2010 15:48:33 +0100

>>>   but take into account new WKPs.

...
> So, I'd actually suggest that we go for 1) or 2) but soften that a bit, like: "if it is known by some external method that the prefix includes an IPv4 address, the representation MAY print it in dotted decimal".

+1
IMHO, the MAY is THE solution.

RD

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Jan 2010 12:31:43 +0200

Pekka, Brian, Juergen,

Good enough for me as well. I have requested an IETF Last Call for the
new version of the document.

Jari