[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Mark, Stig,

On 25 Jul 2005, at 15:50, Mark Smith wrote:

On Mon, 25 Jul 2005 10:29:42 +0200
Stig Venaas <Stig.Venaas@uninett.no> wrote:

On Mon, Jun 27, 2005 at 06:22:17PM +0930, 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. 

Some of the arguments against /127s
on point-to-point links in RFC3627 "Use of /127 Prefix Length Between
Routers Considered Harmful" may be worth considering in the context of
/128s on loopbacks.

We use /112s for point-to-point links, following Pekka's argument in RFC3627, and haven't yet (touch-wood) experienced any difficulties in so doing.

However, we have tried to ensure that the u/g bits are set appropriately as if they would have the EUI-64 specified meaning were the addresses under a 64-bit prefix, so that should any implementations blindly assume that node addresses have the bottom 64- bits as an interface identifier, the semantics still hold.

Given that this is all under globally aggregatable unicast address space, the topology is such that each /112 will be globally unique and thus the bottom 64-bits unique also, and so the inferred intention of the spec is still obeyed (that is: the bottom 64 bits of the interface's address can be used as an identifier)

I'm still not sure exactly how host routing would work from the
end-nodes point of view

The way I see it the hosts would have physical interfaces connected to a
physical link and have addresses for those doing ND etc as usual. In
addition they would have some kind of virtual interface with some / 128
addresses and somehow inject host routes for those on the physical
interfaces so that next-hop would be the (e.g. /64) addresses on the
physical links. This is how I believe it works today when you use
loopbacks with /128 for routers.

I think that would work. However, even if it is accepted to run some
form of routing protocol on the end-nodes to push host routes into the
routing cloud, there would still have to be a manual address assignment
process for the /128s on the loopback interfaces, because as you
mentioned before, the loopback interfaces probably won't receive any ND
protocol messages such as RAs. That could arguably be considered an
impractical solution "in this day and age", because staticly configured
addresses on hosts in IPv6 is so pre-DHCP IPv4 :-)

One solution might be a new DHCPv6 option to assign addresses on interfaces other than the one we're using to send the DHCPv6 query from. (What would that message look like? Is there scope for some DHCPv6 server-to-router signalling to have the host route injected to the local network, too?)

To hide the network topology from nodes external to this network domain,
then I'd think the /64s assigned to the links would have to be ULAs,
although I think the link-local addresses might be enough to support
forwarding the packets from the edge of the routing domain to the host
within it and vice-versa.

Better pray that you're not using multicast of scopes wider than 5, then ;-) (RFC3484 default policy doesn't bode well when you're using ULAs and multicast together - but that's a different discussion)

The problem there though is that any ICMP messages generated by routers, targeted towards external nodes, such as
Destination Unreachables, Packet Too Big would have "private" source
addresses, and would likely to be dropped by the routers at the edge
that are using source address filtering to prevent things like SYN
attacks. IOW, the same problems that occur now if somebody uses RFC1918
private addresses on their internal links.

This is possibly one of the few cases where address translation is desirable with IPv6: at the border router propagating errors outward, masking the internal routing topology.

I suppose as long as all the routers as well had /128s on loopback
addresses (not a bad idea at all), and as long as the ICMP messages used
the loopback addresses as the source addresses, that problem might not
occur.

Taking traceroute as an example (and likely to be the first utility about which users will complain about not returning useful information...) - what is there to guarantee that the address used for ICMP Time exceeded messages would be the global loopback address of the reporting router, rather than it's ULA/private address of the interface on which the message is generated?


regards,

Mark/

--
Dr Mark K. Thompson
Electronics and Computer Science
a School of the University of Southampton, UK