Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd)

[Iljitsch van Beijnum <iljitsch@muada.com>]

[dropping multi6]

On 21-jun-04, at 13:25, Eliot Lear wrote:

> Okay, the confusion in this exchange stems from which "ingress" we 
> were talking about.

Shame we don't have better terminology here.

> > > We make note of the fact that there is a linkage between the 
> > > upstream ISP and the network.  What perhaps we should state is that 
> > > upstreams may need to know about each other from anti-spoofing 
> > > mechanism.

> > But what if the ISPs aren't prepared to cooperate? Not everyone is a 
> > fortune 1000 company.

> Okay, I follow you.  The draft attempts to cover ground in two areas:

> 1.  That which can be done today;

> 2.  What needs to be fixed.  I believe you're arguing for a fix, and 
> perhaps some text in the draft would be good.

I wasn't arguing for a fix, although an automated way to open up 
ingress filtering by ISPs would be very useful here.

What I am arguing for is acknowledging this issue in the draft so that 
people know what they can do to work around this problem.

> > Actually it is much less complex unless people extensively use 
> > manually configured addresses. The problem with IPv4 is deciding on 
> > subnet sizes, merging subnets, avoiding overlap and so on. None of 
> > this is an issue with IPv6 since everything fits in a standard issue 
> > /64.

> We have saved network managers from requiring a set of spreadsheet 
> operations.  BFD.  The level of complexity is substantially the same.

Actually this is a big deal, as in IPv4 address management is so 
problematic that renumbering pretty much requires manual intervention. 
While I agree that all the other issues, such as the DNS and access 
filters, are also problematic, it's certainly within the realm of 
possibility to automate these issues.

> IPv6 was billed as a great self-configuring does-everything-but-eat 
> follow-on to IPv4.  Very little of that is true today.

Yes, when do we get to discover DNS resolvers automatically?

Other than that the situation isn't as bad as you make it seem.

> We'd like to identify the mechanisms that would improve matters, at 
> least for IPv6. Who knows?  Maybe for IPv4 as well.  For instance, 
> what you're looking for above is some way for providers to learn about 
> customers' alternative published connectivity, such as a more robust 
> and accurate RADB in order to configure ingress access-lists.  One 
> needs to understand who's authoritative for the information, and what 
> the keys are.  Certainly the keys are unlikely to be IP address 
> prefixes :-(

This is pretty much a non-issue as these filters can be created using 
unicast reverse path forwarding (uRPF). However, I agree that better IP 
address authorization information would be good, if we get this then we 
may be able to secure interdomain routing much better. (See S-BGP and 
soBGP, although neither of those is necessary if vendors implement 
better mechanisms to upload long prefix filters to routers.)

> As to whether the providers are willing to implement such a mechanism, 
> I can't say.  They will look for an easier way, and that easier way 
> today is a NAT that does source selection (policy routing).

I don't see the relation between NAT and policy routing. Both are 
harmful, though.