Re: New Version Notification for draft-jiang-v6ops-incremental-cgn

[Brian E Carpenter <[e-mail]>]

Fred,








Regards
   Brian Carpenter
   University of Auckland




On 2009-05-15 03:17, Templin, Fred L wrote:
> Dear authors,
> 
> The document is clean and concise, which is appreciated.
> However, section 3.2 seems to be showing preference
> toward a particular tunneling technology, and I'd like
> to understand that better.
> 
> To understand this, we must first observe that the 6rd
> approach relies on anycast for CPE router accessing of
> IPv6 routers within the IPv4 ISP network. The idea of
> anycast was entertained and abandoned by the ISATAP
> team in the 2001/2002 timeframe when ISATAP was still
> being developed in the ngtrans working group. This came
> after much discussion among authors and guidance from
> the working group. Reasons include:
> 
> 1) if the tunnel fragments, fragments of the same packet
>    may go to different anycast-addressed routers.
> 
> 2) with anycast, there is no opportunity for default
>    router selection (when there are multiple)
> 
> 3) with anycast, there is no opportunity for traffic
>    engineering
> 
> 4) with anycast, IPv6 neighbor discovery over the
>    tunnel may yield unpredictable results

When I look at the 6rd draft, I don't really see why the relay needs
to be anycast - as far as I can see it could be genuinely unicast
(since there is no semantic difference for the CPE or the relay;
it's only anycast if the ISP sets up its IGP to make it anycast).
So the real question is how the CPE knows the 6rd relay address,
which is also a question for RFC3056. There are of course many
possible answers to that, e.g. a DHCP(v4) option.

Personally I think a provisioned unicast address may be better,
because of your points 1-4.
> 
> 5) with anycast, there is need for a manual provisioning
>    of IPv6 prefixes and IPv4 anycast address on the CPE
>    router.

Which IPv6 prefixes? The CPE builds its IPv6 prefix from its
external IPv4 address, which it gets in the traditional way.

> 
> We next observe that the 6rd mechanism is rooted in a
> customized IPv6 prefix configuration that embeds an
> IPv4 address. First, this would require that a quite
> large IPv6 prefix (e.g., a /24) be delegated to the
> ISP were its customers to obtain even a /56 as the
> largest possible prefix. Such a prefix would be used
> only sparsely, as only a small portion of the IPv4
> address space may be available for assignment to CPE
> routers. 

Yes. Are we running out of /24s yet?

> Secondly, the only mode of operation afforded
> is Provider-Aggregated, i.e., there is no provision for
> CPE use of Provider-Independent prefixes.

Yes. I would expect this method to be used for SOHO subscribers,
not for larger customers who might use PI.

> 
> I suspect you know where I'm going with this, but take
> each of the deficiencies named above and apply VET, and
> you will see that VET robustly covers all of these cases
> and more. Indeed, with VET as the phase 1 deployment,
> there would be no need for a phase 2, and no need for
> any IPv6 readdressing as VET uses unmodified IPv6
> prefixes natively.
> 
> The VET model asks only that CPE routers become VET
> enterprise border routers, that CGNs become VET
> enterprise border gateways, and that the ISP name
> service be provisioned with resource records for
> border gateway discovery. In other words, the VET
> deployment touches exactly the same CPE/PE equipment
> that the 6rd approach touches, and VET asks only that
> the ISP network administrators add a few resource
> records to the DNS. If there are doubts as to how
> VET satisfies each of these use cases, I will be
> happy to explain in follow-up.

I don't see this for SOHO subscribers using $50 CPEs,
frankly, but I could be wrong.

     Brian

> 
> In your section 3.6, we note a strong recommendation
> for a tunnel MTU of at least 1500 bytes and I concur
> with this recommendation. Were that not the case,
> customer devices would be constantly inconvenienced
> with excessive ICMP PTB messages reporting degenerate
> MTUs for crossing the ISP network. We also note that
> SEAL uniquely and correctly provides the tunnel 1500
> MTU assurance that incremental cgn is seeking, and
> moreover note that larger MTUs (e.g., 9K) are robustly
> and naturally discovered when customer devices request
> them. Please see also RANGER Scenarios (RANGERS) for
> additional insight into the application of VET and
> SEAL into the ISP network problem space:
> 
> http://tools.ietf.org/html/draft-russert-rangers
> http://tools.ietf.org/html/draft-templin-autoconf-dhcp
> http://tools.ietf.org/html/draft-templin-seal
> 
> Fred
> [e-mail] 
>    
> 
>> -----Original Message-----
>> From: Sheng Jiang [mailto:[e-mail]]
>> Sent: Wednesday, May 13, 2009 5:44 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: FW:New Version Notification for
> draft-jiang-v6ops-incremental-cgn
>> Dear all,
>>
>> A revised version of draft-jiang-v6ops-incremental-cgn has been
> submitted to
>> v6ops WG. It had been represented by Brian Carpenter in v6ops meeting
> in
>> IETF 74 as draft-jiang-incremental-cgn-00 and received positive
> comments
>> also modification comments. We have integrated these comments into
> this
>> version.
>>
>> Please review and comments on it. Many thanks.
>>
>> Best regards,
>>
>> Sheng
>>
>>> Filename:	   draft-jiang-v6ops-incremental-cgn
>>> Version:	   00
>>> Staging URL:
>>> http://tools.ietf.org/id/draft-jiang-v6ops-incremental-cgn-00.txt
>>>
>>> Title:		   An Incremental Carrier-Grade NAT
>>> (CGN) for IPv6 Transition
>>> Creation_date:	   2009-05-08
>>> WG ID:		   Indvidual Submission
>>> Number_of_pages: 11
>>> Abstract:
>>> Global IPv6 deployment was slower than originally expected in
>>> the last ten years. As IPv4 address exhaustion gets closer,
>>> the IPv4/IPv6 transition issues become more critical and
>>> complicated. Host-based transition mechanisms are not able to
>>> meet the requirements while most end users are not
>>> sufficiently expert to configure or maintain these transition
>>> mechanisms. Carrier Grade NAT with integrated transition
>>> mechanisms can simplify the operation of end users during the
>>> IPv4/IPv6 migration or coexistence period. This document
>>> proposes an incremental Carrier-Grade NAT (CGN) solution for
>>> IPv6 transition.
>>> It can provide IPv6 access services for IPv6-enabled end hosts and
>>> IPv4 access services for IPv4 end hosts while remaining most
>>> of legacy IPv4 ISP networks unchanged. It is suitable for the
>>> initial stage of IPv4/IPv6 migration. Unlike CGN alone, it
>>> also supports and encourages transition towards dual-stack or
>>> IPv6-only ISP networks.
>>>
>>> Submitter: Sheng Jiang ([e-mail])
>>>
>>> Author(s):
>>> Sheng Jiang, [e-mail]
>>> Dayong Guo, [e-mail]
>>> Brian Carpenter, [e-mail]
>>>
>>>
>>> Comment:
>>> Replacement for draft-jiang-incremental-cgn-00
>>>
>>>
>>
> 
> 
>