Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ron

On 3 December 2011 22:06, Ronald Bonica <rbonica@xxxxxxxxxxx> wrote:
Folks,

On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because:

- it is difficult. (We are choosing between the lesser of two evils.)
- a lively discussion on this mailing list has not yet converged

Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus:

- Is the reserved /10 required for the deployment of CGN?

The shared /10 is required for the deployment of NAT444. This ensures a standardised, consistent way to identify CGN internal addressing, irrespective of service provider. This also provides the lowest risk of address collision with existing networks.

CGN is a generic term, and in some cases 1918 space can be used - for example, where the CPE is an end-device (single host) that is not providing any additional LAN connectivity, eg mobile devices.

 

- What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4?

The impact of using a single /10 for CGN/NAT444 is far less than each ISP assigning their own dedicated block. Large ISPs would consume a /10 each for this purpose.

 

- Can alternative /10s be used?

The alternatives (discussed) are:
1. RFC1918 space - I do not see that the inside addressing in NAT444 is legitimate use for this space. It is defined as "Address allocation for Private Internets", which ISP customer connectivity is not.

2. 240/4 - I agree that this block should be released for unicast use, however for CGN/NAT444 it is not 'fit for purpose' for use with ALL existing CPE and network hardware.

Perhaps a separate I-D is required to release the 240/4 address block for future use, however this should not be confused with the immediate requirement.

Regards
Daryl
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]