Hi all,
Should IID-format constraints be applicable to IPv6 addresses, even
if they don't contain real IIDs?
I have proposed in various occasions that they would apply only to
addresses that do contain real IIDs.
This mail is to WITHDRAW this proposal, to explain why it was
proposed, and to explain why it is withdrawn.
GENERAL ANALYSIS
New IPv6-address formats are being considered for IPv6 addresses
that, in IPv6/IPv4 NATs, identify IPv4 hosts. Some others are
considered for new tunneling mechanisms, in particular the SAM I
presented in Stockholm for IPv6 multihoming.
In these addresses, the lower 64 bits are not real IIDs:
- RFC 3513 says that "Interface identifiers in IPv6 unicast addresses
are used to identify interfaces on a link").
- The lower 64 bits of these addresses are never "used to identify
interfaces on a link". It is only IPv4 or IPv6 addresses obtained
after some mapping that are used for on-link interface
identification. They in general don't contain the initial lower 64 bits.
We will call such addresses "mappable-only" addresses.
RFC 3513 also says, as we all know, that "For all unicast addresses,
except those that start with binary value 000, Interface IDs are
required to be 64 bits long and to be constructed in Modified EUI-64
format".
We will call this constraint the "IID-format constraint"
Since mappable-only addresses have no real "Interface ID", they may
be interpreted as out of the scope of the IID-format constraint.
If they are indeed out of scope, that's good news because new formats
of mappable-only addresses can be simpler than if they are in scope
(no constraint on the two lower bits of their 9th octet).
If mappable-only addresses should be considered in the constraint
scope, some technical reason for it should at least be documented.
Since no such technical reason was identified, I proposed to make
official that the IID-format constraint doesn't apply to mappable-
only addresses.
Now, it happens that such a technical reason has just been
identified. As explained below, it relates to a subtle attack
possibility with some ISATAP and 6to4 nodes conforming to current
RFCs. The only choice that remains is then to clearly include
mappable-only addresses in the scope of the IID-format constraint.
ROUTING-LOOP ATTACK PROTECTION AND ITS IMPLICATION ON IPV6 ADDRESS
FORMATS
In a mail of Aug 17 (www.ops.ietf.org/lists/v6ops/v6ops.2009/
msg00601), Gabi Nakibly documented a new type of attack: the "routing
loop" attack. With it, some packets can be repeatedly retransmitted
between two ISATAP routers, or between an ISATAP router and a 6to4
relay router.
For a brief illustration of one instance of the the attack, here is
an example:
+-------------------------------------------------------+
| IPv6 IPv6 packet |
|Internet dst6: 2002:198.16.9.9::1 |
| src6: 2001:db8:1::200:5efe:192.88.99.1|
| | |
| V |
| .--------------->--------------. | |
| / \| |
+--------+----------------------------------+-----------+
| |
2001:db8:1::/48 2002::/16
+---------+ +---------+
| ISATAP | | 6to4 |
+---------+ +---------+
198.16.9.9 192.88.99.1
| |
+--------+---------+ |
| IPv4 ^ | |
| site ^ | |
| ^ | V
| ^ | |
+--------+---------+ |
198.16.9.0/24 |
| |
| |
+--------+----------------------------------+-----------+
| IPv4 \ / |
|internet '----------------<-------------' |
| IPv6 in IPv4 packet |
| dst4: 198.16.9.9 |
| src4: 192.88.99.1 |
| |
+--------+----------------------------------+-----------+
Detailed protection mechanisms against these attacks are being
discussed on the v6ops and 6man lists, in particular with Gabi
Nakibly, Fred Templin, and Christian Huitema, and are out of scope
here. Suffice it to say that a 6to4 relay router may need, to be
safe, to look at IPv4 addresses that are embedded in ISATAP IPv6
addresses. In the above example, if the 6to4 relay router sees that
the IPv4 embedded address in the IPv6 destination is its own IPv4
address 192.88.99.1, it can discard the packet and thus prevent the
loop.
Now, IPv4 addresses embedded in ISATAP addresses can be reliably
detected ONLY if non-ISATAP addresses NEVER have 200:5efe::/32 in
their octets 8 to 15. If some mappable-only address would have this
pattern, there could be a slight but real possibility that an
intermediate 6to4 relay would discard packets sent to this address.
This is, in my understanding, a sufficient technical reason for the
IID-format constraint to apply to all IPv6 addresses (with or without
real IID).
Regards,
RD
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
