Subject: Proposed Resolution of Issues [1-37]

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 01 Sep 2005 12:45:29 +0200

The issue list available on http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm has
been updated and addresses the remainder of the issues from the WGLC.

The Consensus answers in marked in blue are the onces that were proposed
last week and have been considered as stable consensus. The proposed resolution
entries marked in red are the onces added today.

Groetjes,
G/

---

From: Tim Chown <[email-masked]>
Date: Fri, 2 Sep 2005 09:33:00 +0100

> entries marked in red are the onces added today.

Looks good.

For issue 5, RFC3041 might hamper that.

On Issue 9, I suspect Kurtis has good figures on this, I recall he did 
back before multi6 reformed and we had multihoming discussions in Michel's
list.  

Issue 10, because admins pick 10.0.0.0/24 or 192.168.0.0/24.  I'll wager
they do the same with ULAs still, but hey :)

Issue 12 ULAs dont aggregate internally either, as each /48 is in effect
a random prefix.  May bug big organisations, who thus may not use 'proper'
ULAs?

Issue 14 - as Stig pointed out, if two remote sites use ULAs they may
prfer to use ULAs between them.   But that could be configured as 3484
policy too.   The key thing is that ULAs now have global scope, so are
by default treated as globals.

Issue 20 - I'm very wary that we should not embed 'best practice' in
firewall configuration in this draft.  I'd say 'less is more' here.

Issue 23 - unique but may change, eg. 3041.  I see little difference from
the ISP view in a customer with a stable single v4 address + NAT and a
customer with a stable /56 prefix and 3041 in use.  The v4 address masks
systems just as the /56 in effect does.

Issue 24 - so what text will you use? :)

Issue 27... hmmmm.  Renumbering complexity has many variables.  A simple
home network with one LAN and no servers/services is as easy as it gets.
I'd assume that most current NAT-using sites don't have many externally
advertised services, but will embed IP addresses in their internal systems
and networks.

Issues 32&33:  ULAs *may* help renumbering, not *will*.  There is baggage 
with ULAs and as such their use is a tradeoff not a given, I feel.

Issue 36: in practice sites will run IPv6 with IPv4+NAT, so they need
to secure two protocols 'on the wire'.

Issue 37: noone is mandating a migration from IPv4+NAT to IPv6.  Indeed
many sites may equally benefit from a migration to use global IPv4 addresses.
One might even consider in the draft how much is IPv6 specific, and how
much is 'use global addresses' specific.

I'll also resubmit the posrt-scanning text soon.

-- 
Tim/::1

---

From: Fred Baker <[email-masked]>
Date: Fri, 2 Sep 2005 14:18:00 -0700

> with ULAs and as such their use is a tradeoff not a given, I feel.

I very much agree. I had the same debate with Pekka and Thomas when  
the renumbering procedure draft went in. Thomas filed a 'discuss'  
requiring me to say that ULAs would simplify renumbering, but without  
saying how. I told them:

On Jan 15, 2005, at 5:46 PM, Fred Baker wrote:
> Listen. If ULAs simplify the procedure of renumbering a network  
> without a flag day, then there should be several places in the  
> document where a few sentences of the following form can be added.
>
>   "if the old prefix..." or "if the new prefix..."
>   "is a ULA prefix then"
>   "...this step may be skipped" or "...this step may be simplified  
> <in this way>"
>   "and it still allows you to renumber a network without a flag day  
> for <this> reason."
>
> Present me with those sentences, and I will include them.

On Jan 15, 2005, at 9:34 AM, Fred Baker wrote:
>> This said, I think it's still good idea to _mention_ ULAs, but  
>> treat them with sufficient skepticism at this point.  The text you  
>> proposed, and which I modified, and suggested in the previous  
>> message:
>>
>>> This document describes issues related to renumbering a network,  
>>> where network addresses need to be changed because the old  
>>> numbers will no longer be usable in the future. Readers should be  
>>> aware that a form of local addressing, Unique Local Addressing  
>>> (ULA) [ULA].  Using ULA addresses doesn't obviate the need to  
>>> renumber networks, but are another tool that may reduce the need  
>>> for or complexity of renumbering networks.
>
> This document, first and foremost, is about a procedure for  
> renumbering a network. Both you and Thomas suggest that ULAs might  
> reduce the complexity involved in numbering networks, but I am at a  
> loss to say how - and in the end, when people ask that question,  
> they will ask it of the authors. In neither the text you propose  
> nor the text Thomas proposes do I see any suggestion of a way that  
> ULAs might alter that procedure in any way. Am I missing something?
>
> If you can't tell me *how* ULAs reduce the complexity in the  
> procedure of renumbering a network, I don't see the mention as  
> relevant.

I have heard a fair bit of dogma about ULAs to the effect that they  
solve something, but have never been presented with those sentences,  
and am not convinced on the rest either. They look to me like a re- 
invention of site-local with many of the same problems.

And by the way, if ULAs are global, they are global addresses... What  
does the "L" stand for?

---

From: Tim Chown <[email-masked]>
Date: Sun, 4 Sep 2005 09:15:24 +0100

> And by the way, if ULAs are global, they are global addresses... What  

I've been wondering that too ;)

-- 
Tim/::1

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Sep 2005 15:48:11 +0200

Fred Baker wrote:
> I very much agree. I had the same debate with Pekka and Thomas when  the 
> renumbering procedure draft went in. Thomas filed a 'discuss'  requiring 
> me to say that ULAs would simplify renumbering, but without  saying how. 
> I told them:
> 

I don't think any of that applies. My take is that ULAs have the advantage
during a renumbering exercise of providing business continuity for
*internal* operations - your printers, for example, can have ULAs
and are untouched (and their DNS entries are untouched) during the
renumbering process. Your internal SMTP system can keep
operating without any change to internal DNS. Etc. So it does take
a number of hosts off the renumbering list - exactly those
hosts that have no external visibility.

<snip>

>> procedure of renumbering a network, I don't see the mention as  relevant.
> 
> 

No. They don't have the problem of ambiguity. In context of massive
hosting centers for hundreds of customers, they are vastly better
than RFC 1918 addresses (which is the comparison my operational
colleagues make).

But you do have to accept that a large number of enterprise
networks *want* private address space precisely because it isn't
supposed to be globally routeable. That may not be intellectually
satisfactory as a reason, but it seems to be reality.

> And by the way, if ULAs are global, they are global addresses... What  

They're not global. They're globally unique but intended for local use.
However, "local" can mean a whole enterprise intranet plus VPNs to its
business partners. In that context, global uniqueness is a desirable
property.

     Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Sep 2005 11:28:53 -0700

So it helps in renumbering by not needing to be renumbered. Same  
would be true if it just happened to be in a different global prefix  
that happened to not need renumbering. I don't think that is an  
argument for or against ULAs, or even an argument about renumbering.  
It is a statement that things that are not at the moment up for  
renumbering probably don't have to be thought about when renumbering.

It seems to me that if one is going to say anything on the topic  
here, one might say that a step one might take early in the game of  
renumbering is to scan the DNS database for names that have more than  
one address, one of which is in the prefix to be renumbered. In any  
such case, one can instantly remove the affected address from the  
name, and all future DNS accesses will be from another prefix (which  
may be a ULA). When one adds the new prefix to DNS, one may include  
these names in doing so. Doing so early will limit the impact of all  
the other steps on the utility of the systems, as the prefix being  
renumbered will not be in use for that system.

ULAs are a special case of that statement, and only apply to local  
systems. And by the way, the above comment doesn't simplify  
renumbering. It adds a step (one which is redundant with a later  
step) and requires memory in some form of what names were affected  
and therefore have to be restored. It makes renumbering more complex.

On Sep 7, 2005, at 6:48 AM, Brian E Carpenter wrote:
> Sometime in the past, I said:
>> If ULAs simplify the procedure of renumbering a network without a  
>> flag day, then there should be several places in the document  
>> where a few sentences of the following form can be added.
>>
>>   "...this step may be skipped" or "...this step may be  
>> simplified  <in this way>"
>>   "and it still allows you to renumber a network without a flag  
>> day  for <this> reason."
>>
> I don't think any of that applies. My take is that ULAs have the  
> advantage during a renumbering exercise of providing business  
> continuity for *internal* operations - your printers, for example,  
> can have ULAs and are untouched (and their DNS entries are  
> untouched) during the renumbering process. Your internal SMTP  
> system can keep operating without any change to internal DNS. Etc.  
> So it does take a number of hosts off the renumbering list -  
> exactly those hosts that have no external visibility.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Sep 2005 08:41:24 +0200

Fred Baker wrote:
> So it helps in renumbering by not needing to be renumbered. Same  would 
> be true if it just happened to be in a different global prefix  that 
> happened to not need renumbering. I don't think that is an  argument for 
> or against ULAs, or even an argument about renumbering.  It is a 
> statement that things that are not at the moment up for  renumbering 
> probably don't have to be thought about when renumbering.
> 
> It seems to me that if one is going to say anything on the topic  here, 
> one might say that a step one might take early in the game of  
> such case, one can instantly remove the affected address from the  name, 
> and all future DNS accesses will be from another prefix (which  may be a 
> ULA). When one adds the new prefix to DNS, one may include  these names 
> in doing so. Doing so early will limit the impact of all  the other 
> steps on the utility of the systems, as the prefix being  renumbered 
> will not be in use for that system.
> 
> systems.

That's true. Because IPv6 networks may have multiple simultaneous prefixes
as a matter of course, that check always seems to be needed.

> And by the way, the above comment doesn't simplify  
> renumbering. It adds a step (one which is redundant with a later  step) 
> and requires memory in some form of what names were affected  and 
> therefore have to be restored. It makes renumbering more complex.

It's the observation that a site may have N prefixes only some of
which are being renumbered that adds complexity, I think. In this respect
I don't see that a ULA prefix is any different from an RIR-allocated
prefix that is only used internally - i.e. I see no architectural
change here. (This is another face of the assertion that ULAs behave
like global addresses.)

     Brian

>>> flag day, then there should be several places in the document  where 
>>> a few sentences of the following form can be added.
>>>
>> can have ULAs and are untouched (and their DNS entries are  untouched) 
>> during the renumbering process. Your internal SMTP  system can keep 
>> operating without any change to internal DNS. Etc.  So it does take a 
>> number of hosts off the renumbering list -  exactly those hosts that 
>> have no external visibility.
> 
>