Subject: IPv6 prefix notation

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 Sep 2011 23:19:11 +0200

Begin forwarded message:

> The following errata report has been submitted for RFC6147,
> "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers".

> Original Text
> -------------
> An implementation SHOULD include the ::ffff/96 network in that range by default.

> Corrected Text
> --------------
> An implementation SHOULD include the ::ffff:0:0/96 network in that range by default.

We had some private discussions and there was a difference of opinion whether leaving out the zero part of an IPv6 prefix is ok, same as in IPv4. For example:

10/8
2001:470:1f0b:1289/64

Doing this doesn't seem to be harmful even if systems may not accept these prefixes. Except in the case from the DNS64 RFC, where leaving out zeros on both sides in ::ffff/96 makes it impossible to tell which 16 bits are the one bits. To add insult to injury, ::ffff/96 is in fact a somewhat valid prefix, but not the one we had in mind, with unexpected results:

$ sudo ifconfig gif0 inet6 ::ffff/96
$ ifconfig gif0
gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
	inet6 ::0.0.255.255 prefixlen 96

And the existing guidance in http://tools.ietf.org/html/rfc5952#section-7 dismisses that prefixes have a problem.

Thoughts?

My position is that prefixes should always end in :: so the address part is a valid address and the same code can be used to parse addresses, prefixes and addresses with a prefix length.

---

From: Nathan Ward <[email-masked]>
Date: Tue, 20 Sep 2011 09:23:51 +1200

> My position is that prefixes should always end in :: so the address part is a valid address and the same code can be used to parse addresses, prefixes and addresses with a prefix length.

Agreed. Shortening IPv4 addresses to things like 10/8 makes sense because we don't have another way to do shortening. If we did (i.e. 10../8 or something) then we'd use that.

--
Nathan Ward

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Sep 2011 11:02:00 +1200

> Agreed. Shortening IPv4 addresses to things like 10/8 makes sense because we don't have another way to do shortening. If we did (i.e. 10../8 or something) then we'd use that.

It's unfortunate, I think, that RFC 4291 just says:

      The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.

It would better if it also specified where to use :: if there
is more than one run of zeros. As in

      If an address contains more than one group of zeros where "::"
      could be used, only the {least|most} significant such group
      may be represented by "::".

Take your pick between "least" and "most".

If we don't have such a rule, I fear that the only unambiguous rule for
prefixes is to avoid abbreviation.

   Brian

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 19 Sep 2011 19:19:34 -0400

> prefixes is to avoid abbreviation.
The errata to RFC 4291 offer more clarity in the use of :: in an address
http://www.rfc-editor.org/errata_search.php?rfc=4291

I believe the convention when more than one sequence of zeros meets
the criteria is to compress the longest such sequence.

-K-

>   Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 20 Sep 2011 01:21:23 +0200

Hi,

> prefixes is to avoid abbreviation.

I think that RFC 5952 (an update on RFC 4291) provides the guidance you describe in section 4.2.3.

- Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Sep 2011 15:34:55 +1200

> I think that RFC 5952 (an update on RFC 4291) provides the guidance you describe in section 4.2.3.

I see that it does (and the errata on 4291 do not). Thanks.

A reasonable prefix will end with at least 64 zeros, so :: will
always be the last element according to RFC 5952. (Unless someone
uses prefixes longer than /64, in which case I for one don't care.)

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Sep 2011 05:58:23 +0200

> uses prefixes longer than /64, in which case I for one don't care.)

a shame.  once upon a time, the academics in the ietf did care about
operational networks.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Sep 2011 16:50:32 +1200

> a shame.  once upon a time, the academics in the ietf did care about

I'm not sure that I've yet seen a case where >64 is operationally
justified, except for the /126 or whatever discussion we had a while
back for pt2pt links - where I don't think the problem that started
this thread would apply.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 19 Sep 2011 21:59:00 -0700

> back for pt2pt links - where I don't think the problem that started

(only slightly trolling)

For multi-router subnets where I'm still trying to head the potential
for ND related DDOS while allowing for a reasonable number (or perhaps
the minimum necessary) of devices I'm likely to use a prefix longer than
a /64 but shorter than a /126, because I'm queer on nibble boundaries it
might be a /112 but it might just as easily be a /124.

joel

---

From: [email-masked]
Date: Tue, 20 Sep 2011 09:58:14 +0200 (CEST)

> back for pt2pt links - where I don't think the problem that started

For pt2pt SDH links you want /127 to avoid the ping-pong problem,
not /126.

In any case, there are plenty of providers (including some of the 
world's biggest) which have chosen to use prefixes longer than /64
in their networks - so obviously *they* think it is operationally
justified.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Sep 2011 11:03:32 +0200

> For pt2pt SDH links you want /127 to avoid the ping-pong problem,

That's nice (as long as your routers ignore the all zeros anycast address), but the question was: how do we write down IPv6 prefixes? Are we ok with simply leaving off the undefined part, or do we insist on proper inclusion of the zeros? If the former, how do we avoid ambiguity for prefixes such as ::ffff/96?

---

From: Stig Venaas <[email-masked]>
Date: Tue, 20 Sep 2011 09:34:46 -0700

> That's nice (as long as your routers ignore the all zeros anycast address), but the question was: how do we write down IPv6 prefixes? Are we ok with simply leaving off the undefined part, or do we…

I agree it is ambiguous in some sense. That is, I expect any reasonable
implementation to treat ::ffff/96 as ending in ffff, and being
equivalent to ::/96.

However, for us humans, why would you write ::ffff/96 and not ::/96? I
think one can pretty much expect that the bits beyond the prefix length
are 0 when writing prefixes.

I don't see a big deal with using ::ffff/96 as a sloppy notation on
whiteboards etc. But for documents like Internet Drafts and RFCs, we
should probably make sure to write the trailing 0s.

I myself having got some pushback for writing e.g. 239/8. Even though
it is not ambiguous.

Stig

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Sep 2011 02:09:03 +1000

In message <[email-masked]>, Iljitsch van Beijnum writes:
> That's nice (as long as your routers ignore the all zeros anycast address), but the question wa
> s: how do we write down IPv6 prefixes? Are we ok with simply leaving off the undefined part, or
>  do we insist on proper inclusion of the zeros? If the former, how do we avoid ambiguity for pr
> efixes such as ::ffff/96?

Always specify all 128 bits.  Most of the time the minimal
representation will end in :: occasionally it won't.  For the prefix
in question the preferred representation is "::ffff:0.0.0.0/96" but
"::ffff:0:0/96".

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Sep 2011 23:56:00 +0200

> implementation to treat ::ffff/96 as ending in ffff, and being

This is interesting, because the intended meaning was 0:0:0:0:0:ffff:0:0/96, with the logic being that the last two zeroes are not part of the first 96 bits so they can be left out.

So I think we can conclude that confusion is possible...

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 22 Sep 2011 09:34:32 +0200

> implementation to treat ::ffff/96 as ending in ffff, and being

mostly... 
 
> However, for us humans, why would you write ::ffff/96 and not ::/96?

Because I want to specify the address of an interface and its on-link
network space at the same time.

> I think one can pretty much expect that the bits beyond the prefix length
> whiteboards etc.

For the reason I gave, I don't think so. I don't want a sloppy notation
to be in use to force me to context-sensitive parsing of addresses; this
will lead to mistakes, when the context is lost. Especially probable with
whiteboard notation which will copied manually, maybe only partially...

> But for documents like Internet Drafts and RFCs, we

With this I agree.
 
> I myself having got some pushback for writing e.g. 239/8. Even though

Well, but the shortened notation for IPv4 networks has its roots in the
classful and pre-classful IPv4 notation, and is justified from there at
least to some degree... we don't have that... luxury... with v6. On the
other hand, we did specify a syntax for shortening (compression of zeros)
for IPv6, so let's stick to that, even in our whiteboard notes.

Regards,
	-is

---

From: "t.petch" <[email-masked]>
Date: Fri, 23 Sep 2011 14:56:25 +0200

----- Original Message -----
From: "Ignatios Souvatzis" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 22, 2011 9:34 AM
> > >That's nice (as long as your routers ignore the all zeros anycast address),
but the question was: how do we write down IPv6 prefixes? Are we ok with simply
leaving off the undefined part, or do we insist on proper inclusion of the
zeros? If the former, how do we avoid ambiguity for prefixes such as ::ffff/96?
> network space at the same time.

Which I think a mistake.  They are two separate pieces of information and
there is no standard way of writing that, as this thread has identified.

RFC5952 has been cited as settling the question, but it does not.  That RFC
specifies a 'IPv6 Address Text Representation', it does not specify a notation
for prefixes, or for prefixes and interface addresses combined in one token.
'/' mostly appears in that RFC as part of a URL, with only a brief mention of
its use in 'whois', never as part of the formal specification, so prefixes just
are not covered there.  Nor do I recall  any discussion in the lead up to
that RFC of how to specify a prefix or prefix/address combination.

So if I saw ::ffff/96, I would assume that the writer did not fully
understand IPv6 addresses and would want to clarify the matter
before placing any reliance on it.

IPv4 is different.  We don't have the long strings of zeroes that could
appear anywhere, we know that if the representation is incomplete, then
it is the most significant part that is present, the least significant part that
must be supplied.

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Sep 2011 08:22:14 +1200

Tom,

On 2011-09-24 00:56, t.petch wrote:
...
> zeros? If the former, how do we avoid ambiguity for prefixes such as ::ffff/96?

We can't, so all zeros have to be included, it's pretty obvious after this
discussion. So, a prefix is an address followed by /<length> and an address
is as documented in 5952.

    Brian

---

From: "t.petch" <[email-masked]>
Date: Sat, 24 Sep 2011 12:11:19 +0200

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 23, 2011 10:22 PM

> is as documented in 5952.

Well, that is a good proposal, but I would suggest that unless and until it is
incorporated in an RFC, then it remains a good proposal rather than a standard
or agreed convention: RFC5952bis anyone:-)

Tom Petch