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
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<t...@globis.net>
To: kawamu...@mesh.ad.jp, kawashi...@necat.nec.co.jp
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"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAky3l7QACgkQcrhTYfxyMkLNdwCcDFUxXRmHOgUgWU8M7VLvU1Y1
mdkAn0WfEquXKqW7PbBK32/Tti4/5oec
=PPUG
-----END PGP SIGNATURE-----
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
