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

[Eliot Lear <lear@cisco.com>]

Iljitsch van Beijnum wrote:

> Ok, first comment is relevant to multi6:
>
> Having two prefixes at the same time lands you squarely inside the 
> domain of draft-huitema-... 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.

> In the case of changing addresses where both address ranges come from 
> the same ISP this could be the case, but I don't see how this would be a 
> regularly occurring event (after the 6bone has been shut down). In the 
> case that both prefixes come from different ISPs, the network 
> essentially becomes multihomed periodically, so it suffers all the 
> ingress filtering trouble that we've been discussing in multi6. 

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.

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

> 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. There are three ways this can happen:
>
> 1. disable ingress filtering for one ISP and route everything over that ISP
> 2. use policy routing or some other source address based routing to 
> route packets to the ISP matching the source address
> 3. have a flag day

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.  The renumbering document does not attempt to solve the 
multi6 problem.

> Talking about flag days: I'm missing a discussion on making use of the 
> possibility of deprecating a prefix when stateless autoconfiguration is 
> used. This mechanism makes it possible to move all new (outgoing) 
> sessions to a new prefix in a couple of minutes.

This is a best case scenario that assumes all the appropriate linkages 
for reverse dns lookups that almost assuredly don't exist, not to 
mention the TTLs that are present.  If what you wrote above was the 
general case I wouldn't have cared to get involved in such a document.

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

Want to make it easier?  Great.  I'm all ears.  Perhaps that will be the 
killer app for IPv6, but I doubt it.  My motivation was really to make 
incremental progress on eliminating the need for site-local and natting.

Eliot