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

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

Iljitsch van Beijnum wrote:
> My point is that if you have two prefixes from two ISPs (which I think 
> is the most common situation in renumbering, and it's certainly common 
> enough to be worthy of discussion in a renumbering draft) and both ISPs 
> do ingress filtering (which is also something that can't be discounted) 
> then "turning on" both prefixes at the same time without additional 
> measures is going to lead to problems as packets routed to ISP A may 
> have a source address from the prefix from ISP B (or vice versa) and 
> thus be dropped due to ingress filtering.

Right, I agree.

>> 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.


> 
>> One of us has missed the point.  Firewalls today filter packets based 
>> on destination address.  While I would agree that filtering on a 
>> source FROM the Internet would be foolish, different hosts on the 
>> perimeter may require different levels of protection.  Regardless, 
>> those rules exist today inside firewalls and would need to be changed, 
>> and that's what we're saying.
> 
> 
> Yes, but this has very little to do with ingress filtering by ISPs, so 
> the current text obscures the issue rather than illuminate it.

Two different points.

> 
>>> It's just that tracking the attacks down takes longer. The real issue 
>>> is that you MUST deliver packets to the ISP that matches the source 
>>> address or you have no connecitivity.
> 
> 
>> This configuration either exists prior to the renumbering events or it 
>> doesn't.  If it does it would need to be modified to match the new 
>> addresses.
> 
> 
> Nonsense. The existence of two prefixes at the same time is exclusively 
> related to renumbering in non-multihomed networks, so it has no relation 
> to the state of the network either before or after renumbering.

Except of course for currently multihomed sites.

> 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.


> 
> Obviously there is lots of other stuff that remains the same but what 
> else is new.
> 
>> Want to make it easier?  Great.  I'm all ears.
> 
> 
> There are some pages in my book about renumbering (in IPv4). Feel free 
> to borrow from that (not the literal text, of course).


IPv6 was billed as a great self-configuring does-everything-but-eat 
follow-on to IPv4.  Very little of that is true today.  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 :-(

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).

Eliot