> From: RJ Atkinson <[email protected]>
>> However, on the IPv6 side, I don't know how ILNPv6 nodes would carry
>> the ILNPv4 node's locator - perhaps in an ... option?
This general area (ILNPv4/ILNPv6 interopation) turns out to raise many
points. (I personally had never thought about it, since I always thought of
ILNP as IPv6-only.) The message below started out smaller, but grew like
Topsy as I followed all the various possible design branch-points. I _think_
I have the analysis right, but it's a complex area and I may well have made
errors - if so, my apologies in advance, and I would be grateful for any
illumination of my errors.
It seems from your reply (below), and the impliciations/inferences that flow
from it, that the people working on ILNP haven't examined this area in detail
either?
> Using an option is clearly one possible design choice.
> The simplest design option might be just to map a 32-bit IPv4 prefix
> into the ILNPv6 Locator field in a structured way. RFC-4291, Section
> 2.5.5, defines at least 2 different ways that such a mapping might be
> performed.
I hadn't considered that general possibility (i.e. embedding the IPv4 locator
in an IPv6 destination address), but the specific format(s) defined in
RFC-4291 ("IPv4-Mapped IPv6 Address") is almost certainly not workable.
That's because while an ILNPv6 packet is syntactically identical to a plain
IPv6 packet, the same is not true of an ILNPv4 packet and a plain IPv4
packet. I.e., the IPv6->IPv4 packet boundary requires different packet
processing than ILNPv6->ILNPv4.
In other words, for an ILNP packet to correctly transit the IPv6->IPv4
boundary, the ILNP packets must be processed only at an ILNPv4/6 translator
box, otherwise a correctly formed ILNPv4 packet will not be generated. To put
it another way, generic IPv4/6 translating routers will not correctly handle
ILNP packets.
So, ILNPv6 packets headed towards an ILNPv4 node must be correctly directed
towards an ILNPv4/6 translator box - and trying to arrange that via native
IPv4-in-IPv6 routing (by embedding the ultimate ILNPv4 destination in the
IPv6 packet's destination address) will likely fail. That's because if the
standard, generic, IPv4-in-IPv6 routing tables are relied on, the packet is
likely to arrive at an ordinary IPv4/6 translating router, which will not
correctly perform the ILNPv6->ILNPv4 conversion.
If a different part of the IPv6 namespace were used to hold ILNPv4 locators,
and only ILNPv4/6 translator boxes injected routes to that part of the IPv6
namespace into the IPv6 routing, the difficulty above would not happen.
However, then esentially the entire IPv4 routing table must be injected into
the IPv6 routing _twice_. I.e. once for 'ordinary' IPv4<->IPv6 traffic (which
can use generic IPv4/6 translating routers), and once for ILNPv4<->ILNPv6
traffic (which has to use ILNPv4/6 translator boxes). (The "essentially"
above is because parts of the IPv4 namespace which do not contain _any_
ILNPv4 locators need not be injected.)
If that is not feasible (and although I obviously cannot predict with any
accuracy whether the community will decide to do that, it seems unlikely to
me that the community will accept injecting the entire IPv4 routing table
twice), then ILNPv6/v4 interoperation becomes, as best I can tell, fairly
painful.
Going down the 'all IPv4/6 translating routers must also be ILNPv4/6
translator boxes' path probably doesn't work.
First, that would require that the ILNPv4/6 packet conversion process is i)
standardized, ii) mandated for deployment in all IPv4/6 translating routers,
and iii) become deployed in all IPV4/6 translating routers (otherwise you
have the original problem - ILNPv6 packets arriving at an IPv6->4 boundary
box which cannot correctly translate them). That seems fairly unlikely.
However, even if it were, that still doesn't solve the problem. That's
because, as observed above, an ILNPv6 packet is syntactically identical to a
plain IPv6 packet. In other words, such an IPv4/6 translating router cannot
tell, _simply from looking at incoming IPv6 packets_, whether it needs to
apply IPv6->IPv4 processing, or ILNPv6->ILNPv4 processing. I.e. such a dual
IPv6-IPv4/ILNPv6-ILNPv4 box cannot be stateless, but must know (probably from
wiretapping the ICP) that incoming IPv6 packets are ILNPv6 or plain IPv6.
So that leaves, as the only feasible approach, specifically directing traffic
through ILNPv4/6 translator boxes. However, that is also difficult. There are
several reasons for that; the main ones revolve around the fact that an
ILNPv[46] node which wishes to communicate with an ILNPv[64] node (i.e. the
other flavour) must find, select and use an ILNPv4/6 translator box. However,
in addition to all the problems inherent in that (and they are not trivial,
as experience with similar 'intervering box' designs has shown), there are
some that are specific to ILNP.
One big one is that since one has one more semantic entity one needs to
include in cross-border ILNPv6 packets (the translator box's address), such
packets have a different format than IPv6-local ILNPv6 packets. Since ILNP is
implemented in the hosts, this further implies that all hosts will have to
know the two different formats, and emit the correct type, depending on the
destination.
Interestingly, and most problematically (now that I think of it), similar
reasoning applies to the ILNPv4->ILNPv6 packet boundary - but unfortunately
it applies no matter what approach one takes, since putting the destination
locator directly in the packet is not possible (because of the practical
issue that one cannot embed the IPv6 address space in IPv4.)
In other words, for _any_ ILNPv4/6 interoperation scheme, the destination
address in the IPv4 header cannot be the locator of the ILNPv6 node, but
rather must be the address of an ILNPv4/6 translator box (and the locator of
the ILNPv6 node must be carried elsewhere). I.e. one cannot pull the
'double-inject' hack for the ILNPv4->ILNPv6 interface.
So the bottom line seems to be that to achieve ILNPv6/4 interoperation:
- On the ILNPv4 side, there is no choice, ILNPv4 nodes must know separate
v4-v4 and v4-v6 formats, and participate in ILNPv4/6 translator box
selection/maintainence, etc.
- On the ILNPv6 side, one has to either i) one injects the IPv4 routing table
into the IPv6 routing twice, or ii) ILNPv6 nodes must know separate v6-v6 and
v6-v4 formats, etc.
If ILNPv6/4 interoperation is important (and I have no preconceptions if it
is required or not), there do seem to be some fairly significant issues here.
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
