Subject: Review requested: draft-kawamura-ipv6-text-representation-02

From: Brian Haberman <[email-masked]>
Date: Tue, 12 May 2009 06:41:00 -0400

6MAN WG,
      A document (draft-kawamura-ipv6-text-representation-02) has been 
sent to the v6ops list for comment.  The ADs and chairs have determined 
that it is more appropriate for the 6MAN WG since we are the home for 
any work updating the base specifications.  This draft proposes changes 
to the textual representation of IPv6 addresses in order to avoid 
confusion between different ways of writing the same address.

      I would like the WG to review and comment on this document on the 
list.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2009 09:32:17 +1200

Hi,

The -02 draft hasn't been posted yet, but I've seen a preview,
and I fully support it (the comments I made earlier on the v6ops
list have been incorporated). In fact, I think it should probably
be a BCP, since it recommends what is already done in many
implementations.

     Brian C

On 2009-05-12 22:41, Brian Haberman wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 May 2009 06:34:43 +0200

> be a BCP, since it recommends what is already done in many

+1

The NETMOD WG is currently adopting the same format as the canonical
representation of IPv6 addresses.

/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: Dave Thaler <[email-masked]>
Date: Thu, 14 May 2009 10:40:41 -0700

I read and I agree with the document except for Appendix A.

For one, I disagree that v4 mapped addresses are not recommended.
They're commonly used for sockets that support both IPv4 and IPv6.

Secondly, ISATAP (RFC5214) and IPv4-translated (RFC2765) addresses
are not mentioned and they also use the decimal form in the low 32 bits.

I would recommend moving up into the body of the doc a discussion
of the ambiguity between, for example
::ffff:127.0.0.1
::ffff:7f00:1

And explicitly recommend that forms for which dotted decimal is
legal should always be displayed with dotted decimal rather than
hex.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Haberman
> Sent: Tuesday, May 12, 2009 3:41 AM
> To: IPv6 WG Mailing List
> Cc: [email-masked]
> Subject: Review requested: draft-kawamura-ipv6-text-representation-02
> 
> 6MAN WG,

---

From: Brian Haley <[email-masked]>
Date: Thu, 14 May 2009 14:31:03 -0400

> They're commonly used for sockets that support both IPv4 and IPv6.

I would agree with Dave.  If you ssh to any recent Linux system over IPv4 you'll
see a mapped address since sshd only opens an IPv6 socket:

# netstat -an | grep 22
tcp6       0      0 :::22                   :::*                    LISTEN
tcp6       0      0 ::ffff:10.202.1.26:22   ::ffff:10.0.0.39:49571  ESTABLISHED

Some OSes hide the ::ffff:, some don't, but it's not a security or portability
issue.

-Brian

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 May 2009 11:58:49 -0700

I'll note that the netstat output below is arguably non-standard since it includes 
port numbers without encosing the address in [].
(The arguable part is whether [] is limited to URLs or applies in general)

Windows would display them as [::]:22 etc.

Perhaps this draft should be extended to cover text representation 
of IPv6 addresses + ports, and discuss this issue?

-Dave
________________________________________
From: Brian Haley [[email-masked]]
Sent: Thursday, May 14, 2009 11:31 AM
To: IPv6 WG Mailing List
Cc: Dave Thaler; Brian Haberman
Subject: Re: Review requested: draft-kawamura-ipv6-text-representation-02

# netstat -an | grep 22

-Brian

---

From: Brian Haley <[email-masked]>
Date: Thu, 14 May 2009 17:25:11 -0400

FWIW, I've never seen netstat (or ifconfig, etc) display IPv6 addresses inside
[] on either UNIX or Linux, and that probably won't change anytime soon.  I
thought RFC 3986 only applied to URLs and the like, not command output.

-Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2009 09:44:31 +1200

> of the ambiguity between, for example

Yes. There is a technical ambiguity in RFC4379 caused by this.
http://www.rfc-editor.org/errata_search.php?eid=1418

(You can argue that the suggested fix is sloppy too, but at least it
isn't ambiguous. If we agree here, I can ask the RFC Editor to update
the fix.)

> (The arguable part is whether [] is limited to URLs or applies in general)

As far as I know it's defined for URIs in RFC3986 and SIP in RFC3261.

> of IPv6 addresses + ports, and discuss this issue?

The combination of RFC3261 and draft-ietf-sip-ipv6-abnf-fix
is supposed to combine the RFC4291 syntax, the RFC3986 square
brackets, and :port, such that [::]:22 would indeed be the result,
whereas 127.0.0.1:22 would be the result for IPv4.

http://[2001:4860:b003::68]:80 works fine with Firefox and IE.

I agree that it would be reasonable to recommend this as best practice.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 May 2009 10:11:38 +1000

> I agree that it would be reasonable to recommend this as best practice.

	[] is a kludge to get around protocols that had ":" already
	embedded as a token seperator.

	ISC looked at this over 10 years ago when we were developing
	BIND 9 and went with <address>#<port> where address can
	have a scope identifier %scope.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 May 2009 17:13:12 -0700

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, May 14, 2009 2:45 PM
> To: Dave Thaler
> Cc: 6man

I agree the suggested fix isn't ambiguous and hence fixes the problem.
However it doesn't follow the :: recommendation or the lower-case
recommendation.  I'd probably recommend using
::ffff:127.0.0.0/104
in the errata (::ffff:7f00/104 would of course be ambiguous/incorrect).

> As far as I know it's defined for URIs in RFC3986 and SIP in RFC3261.

Yep.

> I agree that it would be reasonable to recommend this as best practice.

Yep, the problem with the notation quoted in Brian Haley's email is
that "2001:4860:b003::68:80" when viewed without knowing the context
is ambiguous as to whether it's an IPv6 address, or an IPv6 address +
port 80.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2009 12:53:41 +1200

Mark,

On 2009-05-15 12:11, Mark Andrews wrote:
...
> 	have a scope identifier %scope.

If we could rewrite history

a) TimBL would not have relied on semantics to distinguish
names from addresses in URIs

b) IPNGWG would have chosen a different separator than :

but I think we can't rewrite history. We had this discussion
prior to RFC3732 iirc.

    Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 15 May 2009 10:05:08 +0900

> is ambiguous as to whether it's an IPv6 address, or an IPv6 address +

Yes, this is the most ambiguous of the situations.

BTY, FreeBSD gives. I'm pretty used to this.
133.205.1.1.80
2001:260::1.80

IMHO, the way port numbers are presented is not really
a big problem if we don't get something as Dave noted.

Would it make sense to include somewhere a sentence that says something like
"It is recommended that one avoids an ambiguous separtor when
displaying addresses and port numbers together"?

Seiichi Kawamura

---

From: Dave Thaler <[email-masked]>
Date: Thu, 14 May 2009 18:14:53 -0700

> Sent: Thursday, May 14, 2009 6:05 PM
> To: Dave Thaler
> Cc: 6man; Brian E Carpenter
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Personally, I'd rather see a recommendation that everything use
the same separator whenever possible, rather than recommending 
that everything use some separator that isn't ambiguous.

Otherwise, you run into lots of conversion problems when you
try to pass strings between different protocols/apps/
management tools/etc.  Sometimes that's unavoidable, but
the point of a recommendation is to avoid problems
whenever you can.

-Dave

> Seiichi Kawamura
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> 
> iD8DBQFKDL/EcrhTYfxyMkIRAhyxAJ47YJ4w9QHjvaRY2TCiUBRvBFaXJgCeNQF1
> lFyVqX2q62QkCwDVTmefEBs=
> =7ZvM
> -----END PGP SIGNATURE-----

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 May 2009 11:22:56 +1000

> but I think we can't rewrite history. We had this discussion

	We are constrained to use ":" for some protocols.  Using
	[] when so contrained make sense.

	Forcing [] when not so contrained does not make sense.
	It's the tail wagging the dog.

	Mark

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 15 May 2009 15:00:48 +0900

>> the point of a recommendation is to avoid problems

You do have a point there.

WindowsXP(netstat)  [2001:db8::1]:80
FreeBSD7.1(netstat)  2001:db8::1.80
FreeBSD7.1(ipfw)     [2001:db8::1]:80
Linux CentOS4(netstat) 2001:db8::1:80
linux+apache   [2001:db8::1]:80

square brackets may be the more popular
but this is debatable. For example
Unbound's log gives "2001:db8::1 port 53"
and that's not so bad.

Are there others who think this should be
covered in the draft? Any ideas?

Regards,
Seiichi

> BTY, FreeBSD gives. I'm pretty used to this.
- --------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
- --------------------------------------------------------------------

- --
##########################################
NEC BIGLOBE Ltd.
   Platform Systems Division
   Seiichi Kawamura <[email-masked]>
   TEL   : 03-3798-6085 (FAX: 03-3798-6029)
   Mobile: 090-1547-4791
##########################################

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 May 2009 16:42:13 +1000

> Unbound's log gives "2001:db8::1 port 53"

named 2001:500:7::79#53 and 198.133.199.4#53
tcpdump 2001:470:1f00:820:214:22ff:fed9:fbdc.61867 and 207.46.216.54.80

IPv4 added for comparision.
 
> iD8DBQFKDQUQcrhTYfxyMkIRAvquAJ9snCxByDQUqSTBgLA3HMwiVHw+wACfUZwi
> n9VCykOspbJsRJPcLucB8pY=
> =dVSw

---

From: Masanobu Kawashima <[email-masked]>
Date: Fri, 15 May 2009 16:40:14 +0900

Hi Dave, All

Thanks for a lot of comments.

>are not mentioned and they also use the decimal form in the low 32 bits.

I agree with your comment. We had missed these.
These should be included in the document.

>legal should always be displayed with dotted decimal rather than

I agree here also.
These mixed addresses have special meanings.
Also to avoid confusion, I think it should not be converted to hex.

Regrettably, ISATAP and IPv4-translated addresses will converted
to hex in inet_ntop().
Even if we change current code, to deploy new code is not easy.

Regards,
Masanobu Kawashima

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 15 May 2009 10:04:23 -0400

Hi Authors,
   I like the idea of this draft. Thanks for writing this. It would
simplify things a lot for debugging purposes. I do have a couple of
comments on the draft though.

* It is not clear WHO needs to comply with the recommendations in the
draft. i.e. who is the targeted audience?

* I think recommendations 2 and 3 are redundant and can be merged into one.

* I see a missing requirement that states that an occurrence of 2 or
more zero 16-bit groups MUST be compressed. So an address like
2001:0:0:0:0:0:0:1 is still valid according to the current draft.

* I think Appendix D is completely out of place in this document and
should preferably be removed. (I also agree with Dave's comment about
Appendix A)

Thanks
Suresh

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 15 May 2009 23:42:40 +0900

James, Mark

Thanks for the addition to the list.

FYI, I asked my local netops group (that's JANOG) on the mailing list
what their prefernce was, and it came down to two choices.
[] or #. Several comments were made against # (some would
parse it as comment, it is not usable in URIs, etc).

> Solaris does the same as FreeBSD.  Regardless of what future standards
> might say, I suspect it'd be impossible to change for fear of
> compatibility problems.

Maybe so.
If a difference in IPv4 has worked for us thus far,
we may be able to live with the difference in IPv6,
(although I myself would prefer []),
except for Dave's 2001:4860:b003::68:80 example.

Regards,
Seiichi

---

From: Seiichi Kawamura <[email-masked]>
Date: Sat, 16 May 2009 00:56:49 +0900

Hi Suresh

> simplify things a lot for debugging purposes. 

and thank you for taking the time to read and comment!

> draft. i.e. who is the targeted audience?

Section4. states

   recommendation in this document SHOULD be followed by humans and
   systems when generating an address to represent as text, but all
   implementations MUST accept any legitimate [RFC4291] format.

this was advised to me by Brian Carpenter that it was needed.
Does this answer your question?

> * I think recommendations 2 and 3 are redundant and can be merged into one.

I assume you are talking about the conclusion.
Do you think that it should read something like this?

 (2) "::" used to their maximum extent where shortens address the most

I got a similar comment on v6ops BTW.

> 2001:0:0:0:0:0:0:1 is still valid according to the current draft.

You may be right.
I thought '(2) "::" used to their maximum extent whenever possible'
did enough to clarify, but a little rewording might be needed.
Thanks.

> should preferably be removed. (I also agree with Dave's comment about

Appendix A, yes I would go with dot-decimal also.
Appendix D, I don't know. I thought it would be informative
to other operators (since we have to pronounce addresses fairly
often over the phone)...

Thanks
Seiichi

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 15 May 2009 16:57:49 -0400

> From: Seiichi Kawamura [mailto:[email-masked]] 
> 
> Maybe so.

As long as people are giving suggestions, one that seems totally
unambiguous in all respects, and compact, would be to simply as "p" in
front of the port number. Can't be confused with hex, works with IPv4 in
IPv6, or IPv6, doesn't require brackets, and it does not depend on
maximum use of the :: convention.

2001:4860:b003::68p80

Bert

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 May 2009 16:38:09 -0700

Brian,

> If we could rewrite history

Then IPv4 would have had bigger addresses....  :-)

Bob

p.s. Sorry, couldn't resist.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 May 2009 16:45:35 -0700

Hi Bob,

> Then IPv4 would have had bigger addresses....  :-)

I think you did all you could to remedy that, and now
we just need to find a way to make it all play together.

RANGER (and now RANGERS) is IMHO a close approximation
of what the big picture might look like.

Fred
[email-masked]

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Friday, May 15, 2009 4:38 PM
> To: Brian E Carpenter
> Cc: Mark Andrews; 6man; Dave Thaler
> Subject: Re: Review requested:
draft-kawamura-ipv6-text-representation-02

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 15 May 2009 20:19:27 -1000 (HST)

> to other operators (since we have to pronounce addresses fairly

I suspect you'll find the ICAO pronunciation is in more common use than 
the ITU pronunciations among english speakers.  Since english is the 
preferred language for RFCs, if you feel you need to list one example of 
phonetic alphabet, then the ICAO version seems more appropriate. 
Personally, in all my years of playing with radios, I've never heard the 
ITU pronunciation used over the air.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Seiichi Kawamura <[email-masked]>
Date: Mon, 18 May 2009 09:55:30 +0900

Hi Antonio

> the ITU pronunciations among english speakers.  Since english is the

Thanks. I did have doubts about this.

Regards,
Seiichi

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 19 May 2009 11:51:26 -0400

Hi Seiichi,
   Please find responses inline.

> Does this answer your question?

Sounds good. I would like such text to be present in the abstract 
section as well.

>  (2) "::" used to their maximum extent where shortens address the most

I will try to come up with some text for the recommendations.

> did enough to clarify, but a little rewording might be needed.

OK.

> to other operators (since we have to pronounce addresses fairly

I prefer removing it altogether but I am not opposed to having it in the 
document.

Thanks
Suresh