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

Re: ND-proxy applicability and loop-prevention



On Thu, 25 Mar 2004, Erik Nordmark wrote:
> > Stateless address autoconfig mode you're talking about is about 
> > advertising a /64 prefix on the link, with addrconfig flag set, and 
> > onlink flag not set --right?  While the onlink flag gives no 
> > information how the hosts could communicate between themselves, it 
> > still gives the ability to connect multiple hosts on a link -- so it 
> > cannot be used by the ISPs to force "1 user/prefix" -model, right?  
> 
> Not if the link to the ISP is a pt-pt link, and all the case I've seen,
> even if the L2 is broadcast capable such as in cable networks, the topology
> visible to IP seems to be pt-pt.

Counterexamples include bridged xDSL and Ethernet to the Home (without
PPP framing, or advertising the /64 on top of the PPP session).
 
> The ISP can also do strict enforcement if they'd like on top of this.
> For instance, by just letting the first IPv6 address they see coming over the
> link from the subscriber as the only IPv6 address that can be used;
> packets to/from other addresses could be filtered out by the ISP.

Of course -- there is no stopping that.
 
> The basis for needing ndproxy in this case is that the ISP doesn't want to
> explicitly delegate a prefix to their customer. I see two possible reasons
> for this behavior (and there might be more)
>  - the ISP wants to provide tiered services with a single device service
>    at the bottom i.e. only allow one host/IPv6 address

I might reword this slightly, to: "wants to provide tiered services
simply: a) with a /48 delegation, or with either b) /64 link or just
c) one address".  We of course hope that c) would not happen, but have
no power to stop an ISP if they do it in any case.

>  - it is too hard for them to explicitly delegate prefixes

Note that this is not a binary decision, i.e., the ISP might decide
that "OK, it's not too hard for us to delegate the prefixes, but if we
do that, we want some extra payment from the user for the trouble".  
In that kind of environment, ensuring that the users have tools to
cope with a /64 prefix as well would seem to be really important.

For these two basic cases, I think ND-proxy would be applicable in
1.b) (of my own proposition, above) and 2).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------