Subject: Re: [Int-area] Draft input requested for draft-azinger-additional-private-ipv4-space-issues-02

From: Mark Townsley <[email-masked]>
Date: Mon, 01 Mar 2010 11:16:14 +0100

Nice overview, thanks for putting this together Marla and Leo. I have 
just 3 suggestions at the moment:

1. You might mention that some equipment relies upon, potentially 
hard-coded, rules for RFC1918 space. A number of 6to4 implementations, 
firewalls, etc. You touched on this with CPE default configuration, but 
I think it is a bit more broad than that (the firewall example was used 
in a presentation to the int-area in the past, IIRC). The issue with 
6to4 is that a typical 6to4 implementation might consider an IPv4 
address from a "new private IPv4" address range embedded in an IPv6 
address as global, creating black holes for the 6to4 user in areas where 
the Ipv4 address was not reachable. Worse, this would show up as "IPv6 
not working" to someone not versed in what was happening with IPv4, 
further hindering deployment of IPv6.

2. In section 3:

    For instance, it is often technically feasible to use NAT or
    even multiple layers of NAT within the networks operated by
    residential users or corporations where peer to peer communication is
    not needed.    Where peer to peer communication is needed or where
    services or applications do not work properly behind NAT, globally
    unique address space is required.

Certainly, "peer to peer communication" happens through multiple NATs, 
even if it is a lot of work.

I think the more important issue to highlight in place of this is 
build-up of "per-flow" state in equipment and associated 
troubleshooting, management, and operational procedures within new areas 
of the network. In particular, new administrative domains (and 
cost-centers) that had previously not had to pay for maintaining such 
state. This additional state has the potential to limit the number of 
NAPT-mappings per device, not to mention overhead of keeping the 
mappings in place, etc. This problem is not at all limited to 
peer-to-peer applications. For example, some bandwidth-hunting, 
adaptive-rate, video streaming services may be more impacted here, even 
if the application is largely client-server in nature.

The good news, of course, is that if the operator runs IPv6 in addition 
to IPv4, the IPv6 traffic doesn't have to build up such state, 
offloading those resources. But that might be out of scope for your 
document.

3. Finally, it seems odd that "Section 4.1. Unique Globally Scoped IPv6 
Unicast Addresses" is the place we see 
"[I-D.davies-reusable-ipv4-address-block]" referred to as a solution. I 
think section 4.1 can better stand on its own, and that the davies 
document reference belongs as part section 5 (where it already seems to 
be referenced once).

Thanks!

- Mark

On 2/5/10 12:27 AM, Azinger, Marla wrote:
> Hello-
> We have produced a draft document that summarizes the IPv4 Private IP 
> Address issues and alternatives that we face today.  We believe this 
> document belongs in OPSAWG however we would like input from more of 
> the community and for this reason we are posting it to V6OPS and 
> INTAREA mail lists.
> The draft can be found at:
>
> __ 
> <BLOCKED::http://tools.ietf.org/html/draft-azinger-additional-private-ipv4>_http://tools.ietf.org/html/draft-azinger-additional-private-ipv4 
> <BLOCKED::http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-issues-02>_-space-issues-02
>
> Thank you for your time
>
> Marla Azinger & Leo Vegoda
>