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

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

Hi,

"6.2  Subnet topology masking

      There really is no functional gap here as a centrally assigned
   pool of addresses in combination with host routes in the IGP is an
   effective way to mask topology. "

I'm wondering if the above is actually the case. 

I think host routes are easy enough to understand from the point of view
of propagating /128s around within an IGP. 

What I'm curious about is how the end-nodes are configured and how they
operate, in particular when they are attached to a broadcast
multi-access link e.g., an ethernet. Has this operation been discussed or
described in an ID or RFC that I'm not aware of ?

For example, assuming a single IPv6 address assignment (excluding
link-local), if an end-node is attached to an ethernet, what prefix length is
configured for the address that is going to be used as a host route within the IGP ? 

I think a /128 would make sense, which means that this end-node would
then (initially) consider all IPv6 destinations to be offlink, excepting
link-local destinations. The first hop would always be to one or more of
the routers it has learned of via RAs. I'd guess that when this host
tries to send traffic to other IPv6 devices attached to the same (layer
2) link, the router would then issue an ICMP redirect, irrespective of
whether those other devices are also /128 host routed, or more
conventionally using /64 prefix lengths, so that this /128 host could
communicate directly "onlink" via layer 2 to an IPv6 "offlink" device.

Where this possibly gets interesting is for /128 end-nodes, where do
they send a link scoped multicast ? Do they send it only to the routers
they are aware of ? From an IPv6 routing point of view, I'd think that
other than the routers, all other devices would be offlink, because the
prefix length is 128 bits, so those other devices shouldn't receive a
link-scoped multicast from these /128 end-nodes. Does that mean that
these /128 hosts have to layer 2 unicast these IPv6 multicasts to the
visible routers, to ensure that the other nodes attached to the link
don't see the link-scoped multicast ?

Another option could be to assign a really short mask to the address
e.g., for a global address in the 2000::/3 address space, the interface
prefix length would be /3. The node would then consider all devices to
be onlink. For this to work, the router's attached to the link could
then perform proxy-ND for all offlink destinations. It sort of solves
the link-scope multicast issue, although it means that link-scoped
multicasts now have to be forwarded through the cloud to all links that
have /128 host routed hosts on them. I haven't read the ND Proxy draft
yet, I'll presume for the moment that this issue is considered.

All of the above is based on the scenario where a device only has a
link-local and a "host routed" address assigned to it's interface, using
either a /128 or /3 (for global) prefix length. Another couple of
scenarios come to mind which might make things a bit more complicated.
(a) These host routed devices are assigned /64s for the ULA address
space and (b) for simplicity, at the cost of doubling the number of /128
routes, the ULA addresses are also host routed. 

I'd also wonder if and how RAs can be used to supply the /128 or /3
addresses. It doesn't seem that the Prefix Information option would
support providing only 64 bits of prefix, to be combined with a 64 bit
IID, in the case of a global address, to come up with a node address,
yet have then host use a /128 or /3 prefix length on the interface to
indicate on or offlink destinations. Maybe a "prefix length to use"
option would need to be added.

ND Proxy solution might be another alternative that could be suggested
in this ID, as it effectively hides the structure of the links from
external parties.

I need to do some research into these issues, which I'll do tomorrow.
It's 1:10 here in .au, and I'll be going to bed soon. I appologise if
these issues are addressed in an RFC or ID I should have read. If it is
convenient, a URL or two would be useful if they exist.

If these issues aren't described or solved somewhere, I wonder whether
this ID should be recommending host routes as the somewhat preferred
solution to topology hiding ?

Regards,
Mark.

PS. sorry for the length, it got away from me a bit, thanks for reading this far.