Subject: [Fwd: RFC 5292 Comment]

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 15 Oct 2010 08:52:20 +0900

I think this is better discussed in 6man.

"The use of the symbol "::" MUST be used to its maximum capability."

means, you have to represent an address as

2001:db8::1 and not 2001:db8:0:0:0:0:0:1
:: instead of 0:0:0:0:0:0:0:0

I didn't quite understand what you mean here though.

> However, RFC 2373 states that "::" corresponds to the unspecified addresses
> XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

BTW, 2373 is obsoleted by 4291

Regards,
Seiichi

- -------- Original Message --------
Subject: RFC 5292 Comment
Date: Thu, 14 Oct 2010 15:01:11 +0200
From: Test <[email-masked]>
To: [email-masked],    [email-masked]

Sirs, Thanks for your work on IPv6 addresses and operational problems.
We need to get this right to avoid all sorts of nasty bugs.

I have come across a particular problem whilst writing and testing IPv6
library routines that is not addressed in your paper: the handling of
the literal address "::"

Taking your interpretation from section 4.2 of RFC 5952

"The use of the symbol "::" MUST be used to its maximum capability."

then my conclusion is that the literal address "::" == /^::$/ in regular
expression format, should correspond to the all zeros address
0000:0000:0000:0000:0000:0000:0000:0000 (reverse of address compression
= address expansion. it has to be a transparent 2 way process without
loss of information)

However, RFC 2373 states that "::" corresponds to the unspecified addresses
XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

Why is this important to understand?

An often used shorthand for the default route in IPv6 notation seems to
be use of the prefix "::/0"

I was testing my own perl prefix creation libraries, which tested
whether the first portion of the prefix was a valid IPv6 address and it
failed on the case "::/0".

The PERL library Regexp-IPv6 does not seem to recognize that "::" is a
valid address corresponding to the all zeros IPv6 address, because of
this fuzzy definition.

Hoping you can clarify which is the correct interpretation of "::", and
possibly add a section on "Handling Eight 16-Bit 0 Fields"

---

From: Test <[email-masked]>
Date: Fri, 15 Oct 2010 11:23:29 +0200

Thanks for the reply.

Yes I understand what you mean in the definition of address compression.

I'm looking at the reverse direction or address expansion. It should be 
a transparent two-way process.

If a user writes the text "::", what should a program do?

The problem seems to be that there is some confusion over what :: means.

Having thought about this some more I think the problem is the lack of 
clear distinction of special cases of IPv6 ADDRESSES and IPv6 PREFIXES 
in certain RFCs (at least in the heads of some programmers).

A human readable prefix is defined in RFC4291 as:

An IPv6 address prefix is represented by the notation:

       ipv6-address/prefix-length

    where

       ipv6-address  is an IPv6 address in any of the notations listed
                       in Section 2.2.

       prefix-length   is a decimal value specifying how many of the
                       leftmost contiguous bits of the address comprise
                       the prefix.

I guess it isn't always strictly true in IPv6. During PERL library 
testing I've now come across two cases that are grey or have been 
incorrectly implemented. The default route and IPv4 mapped IPv6 addresses.

Here's the default route case.

RFC4291 states that
2.5.2.  The Unspecified Address
    The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
    must never be assigned to any node.  It indicates the absence of an
    address.  One example of its use is in the Source Address field of
    any IPv6 packets sent by an initializing host before it has learned
    its own address.

    The unspecified address must not be used as the destination address
    of IPv6 packets or in IPv6 Routing headers.

In section 2.2
          0:0:0:0:0:0:0:0                the unspecified address

may be represented as

          ::                             the unspecified address

Some libraries and applications have apparently interpreted that to mean 
that you cannot use prefixes defined with :: as the address portion 
because 0:0:0:0:0:0:0:0 is the unspecified address a.k.a. = undefined. 
[Actually the limitation is that it should never be used as a 
destination address]

They therefore interpret by extension that prefixes starting with :: are 
also invalid. This is obviously incorrect.

[just google for: bugs IPv6 default route]

Some clarification that in 5952 Section 7 that :: is a valid address 
portion for use in prefixes would clearly be useful.

Section 2. of RFC 4291 states "In IPv6, all zeros and all ones are legal 
values for any field, unless specifically excluded. Specifically, 
prefixes may contain, or end with, zero-valued fields."

The question apparently remains "can a prefix exclusively be all zeros?" 
I answer yes, because it has not been specifically excluded. Although 
this should be clarified or emphasized, because there are already a 
number of broken implementations out in the field.

May be better to clarify:
"In IPv6, all zeros and all ones are legal values for any field, unless 
specifically excluded. Specifically, prefixes may be completely all 
zeros; and may also start, contain, or end with, zero-valued fields.

Here's the IPv4 mapped IPv6 address case.

The other confusion appears to be if users attempt to use an IPv4 mapped 
IPv6 address to form a prefix, due to the differing prefix-lengths of 
IPv4 and IPv6.

Section 2.3. of RFC4291 states "any of the notations listed in Section 
2.2." i.e. including IPv4 mapped IP6 addresses.

Does the prefix-length refer to the IPv4 portion of the address 
(relative to 32 bits) or to the IPv6 format (relative to 128 bits) or 
neither?

So is ::ffff:a0:0/104 equivalent to ::ffff:10.0.0.0/8 or 
::ffff:10.0.0.0/104 or 10.0.0.0/8 or none of these?

I therefore think there should be some clarification in the RFC 5952 for 
text forms in section 7 re-emphasizing RFC 4291 on prefixes that:

  As per RFC 4291 the IPv6 address prefix is represented by the notation:

       ipv6-address/prefix-length

    where

       ipv6-address    is an IPv6 address in any of the notations 
listed  in Section 2.2 of RFC 4291 excluding IPv4 mapped IPv6 addresses.

       prefix-length   is a decimal value specifying how many of the
                       leftmost contiguous bits of the address comprise
                       the prefix.

Syntax checking rules for checking for valid IPv6 addresses MAY have to 
be modified for some special cases regarding combinations of IPv6 
address and prefix-length when checking the syntax of IPv6 prefixes.

The prefix length SHOULD always be calculated relative to the maximum 
address length of IPv6 i.e. 0 <= prefix length <= 128

IPv4 mapped IPv6 addresses SHOULD NOT be be used as part of an IPv6 
prefix to avoid potential confusion with the meaning of the 
prefix-length. Instead  IPv4 mapped IPv6 mapped prefixes SHOULD be 
represented in text either in pure IPv6 form or pure IPv4 form.

For example
::ffff:10.0.0.0/8 SHOULD NOT be used to represent a text form of an IPv4 
mapped IPv6 prefix
::ffff:10.0.0.0/104 SHOULD NOT be used to represent a text form of an 
IPv4 mapped IPv6 prefix

::ffff:a0:0/104 is a valid IPv6 prefix in text form and MAY be thought 
of being equivalent to the IPv4 prefix 10.0.0.0/8 in text form.

"::" in the context of interpreting an address MAY represent 
0:0:0:0:0:0:0:0 the unspecified address.

"::/128" in the context of interpreting a prefix MAY be interpreted as a 
valid IPv6 prefix and MAY represent the unspecified address.

"::/0" in the context of interpreting a prefix MAY be interpreted as a 
valid IPv6 prefix and MAY represent a prefix that matches any  IPv6 
address (including the unspecified address). This prefix MAY be used to 
denote a default route for forwarding packets without a more specific 
match in the routing table.

Seiichi Kawamura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> From: Test<[email-masked]>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAky3l7QACgkQcrhTYfxyMkLNdwCcDFUxXRmHOgUgWU8M7VLvU1Y1
> mdkAn0WfEquXKqW7PbBK32/Tti4/5oec
> =PPUG
> -----END PGP SIGNATURE-----
>