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

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

On 21-jun-04, at 9:49, Eliot Lear wrote:

> > The draft now assumes that having both old and new addresses works, 
> > and this isn't an assumption you can just make.

> No, we assume that the network is in a nominal state prior to 
> renumbering.  The issue you raise below would indicate that perhaps 
> this *isn't* the case.  In which case your problems are bigger than 
> renumbering.

I don't understand what you're getting at.

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.

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

> > The draft only talks about ingress filtering with regard to security, 
> > which IMNSHO is stupid because there are no attacks that are possible 
> > with spoofed addresses that aren't possible with unspoofed addresses.

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

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

> > All in all I think this draft is suffering from lack of ambition. 
> > Either provide some real guidance rather than a bunch of truisms or 
> > drop the whole thing.

> This draft's ambition is to document the process, and perhaps point 
> out a few areas for improvement in the standards/development front.  I 
> personally think it also shows that the problem is really no less 
> complex than IPv4, and if we add the MULTI6 fun, we could make it 
> moreso.

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.

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