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

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

On 8-jul-04, at 0:27, Fred Baker wrote:

> > A few paragraphs along the lines of "ask one ISP to temporarily 
> > accept packets with the other's addresses and use that one for 
> > outgoing traffic or use policy routing to match ISPs to the source 
> > addresses in outgoing packets, or if these approaches aren't 
> > possible, implement a flag-day type of transition" would be very 
> > helpful, I think.

> In a word, no.

> There was a serious attempt last fall to turn this document, which is 
> about "how to renumber a network", into "how to configure ingress 
> filtering and route traffic within multihomed networks".

Apparently my remark that in many instances, switching ISPs means a 
network effectively becomes multihomed temporarily made you relive some 
kind of trauma. My apologies for that. I would very much like to focus 
on the problem at hand, which is renumbering. As I've said before, a 
good part of all renumbering operations will be because a network 
switches ISPs. In that case any ingress filtering that is present 
becomes a big problem, and the draft doesn't provide sufficient 
guidance in this area, in my opinion.

> In the interest of ever getting a chance to actually do anything 
> useful with "how to renumber a network", Pekka and I put the entire 
> BCP 38 discussion into a separate document, which is now RFC 3704. 
> This working group looked at that document, decided it was sufficient 
> to describe those issues, and published it as an RFC. If it is not 
> sufficient, fixing RFC 3704 is the task of the day,

I disagree. The renumbering draft is the task at hand, and even though 
it's possible to see these issues in a larger context, but as this 
document is supposed to provide operational guidance and this is 
exactly a problem operators will encounter when renumbering.

Some input from the rest of the wg would be beneficial here, btw. I 
don't think Fred and myself are going to reach rough consensus all on 
our own here.

> May I suggest that, by 12 July, you post an updated version of RFC 
> 3704?

Why before july 12th? And you may remember that I've never been a huge 
fan of RFC 3704, so I doubt I'm the right person for the job. I'm more 
interested in fixing the problem rather than fixing the description of 
the problem, anyway. One thing I've thought about in the past is some 
kind of "open sesame" protocol that allows customers to instruct ISPs 
to open up ingress filters in an automated way.