Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

Hi Alain, Fred

On Thu, 30 Jun 2005 12:28:50 -0700 (PDT)
alain@tycool.net wrote:

> >
> > On Jun 27, 2005, at 9:52 AM, Mark Smith wrote:
> >> It looks like a /128 prefix length is not permitted on an interface,
> >> according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means
> >> most of the issues I was concerned about described disappear.
> >
> > For the record, a /32 is now permitted on an interface in IPv4. This
> > permits allocation of such to a loopback interface, for example. It may
> > be worthwhile to find the use cases for that and ask whether they apply
> > to IPv6.
> 

That's what started me down this path of wondering how host-routing on
the end-node worked.

Having used /32s on loopbacks on routers, I started wondering how
they'd work on physical interfaces. Mostly what you are taught about
IPv4 is that a router's IP address has to fall within the subnet
assigned to the link the node is attached to. Then you learn about host
routes and PPP, and find out that isn't necessarily the case.

I then started wondering how a /32 on an broadcast multi-access
interface would work e.g., an ethernet, and if ARP would resolve
addresses that were "offlink" according to the /32 prefix length,
including a directly attached default gateway, 

I haven't done a full test, however with the right static routes
(interface host route for a gateway address, default route point to that
gateway route), Linux will issue ARPs with payload source and
destination IP addresses that don't fall within a particular subnet. I'm
not sure if other devices will respond, maybe they will as long as the
don't perform checks on the subnet membership of the source and
destination addresses in the ARP.

> It is use a lot on servers to increase network reliability.
> Servers configure an IP address on the loopback, publish it in the DNS
> and advertize it via routing protocols.
> I do not see why it will not be used in v6 the exact same way.
> 

Certainly I'd think things should work within IPv6 in the same way.

There are a few inefficiencies in this model though :

(1) If the host only has one interface, using a nailed up loopback
doesn't add all that much value, and in the case of IPv6, costs a /64
subnet (as /128s aren't supposed to be used). Remote nodes may as well
send their traffic towards the (IPv4/IPv6) address assigned to the
physical interface itself.

(2) Running a fully fledged routing protocol on the end-node is
relatively heavy handed for what is being achieved. I'd think a
simple, light-weight announcement style availability protocol for the
node's address, that is part of IPv6 itself, would be useful. 

In the context of the NAP draft and the host routing, topology hiding
suggestion, if the addresses within a /48 aren't grouped into /64
prefixes, with those individual /64s assigned to an individual link, I
don't think the end-node can assume that an IPv6 destination is a link
layer peer even if the address falls within the /64 prefix assigned to
the probable outgoing interface. As only the routing protocol knows
where hosts are actually located in the topology, due the the host
routes, it seems that the end-nodes would need to always assume the
destination is offlink, and if the destination isn't, the router would
issue a redirect towards the link layer peer. From what I understand of
CLNS, this sounds remarkably similar to how it handles the offlink /
onlink destination issue.

Thinking about it more broadly, this topology hiding idea sounds
remarkably like CLNS / IS-IS Level 1 and Level 2 routing. For
sources/traffic outside the /48(s), forwarding is based on a best match
(as in CLNS/IS-IS Level 2 areas), once the traffic reaches the network
topology that falls within the /48, routing then becomes flat, exact
match against host routes to forward to the exact location of the host
(as in CLNS/IS-IS Level 1 areas). 

Regards,
Mark.