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

["Templin, Fred L" <[e-mail]>]

> -----Original Message-----
> From: Templin, Fred L
> Sent: Friday, May 15, 2009 5:18 AM
> To: Sheng Jiang; Brian E Carpenter
> Cc: [e-mail]; [e-mail]; Fleischman, Eric; Russert, Steven W; Rémi Després
> Subject: RE: New Version Notification for draft-jiang-v6ops-incremental-cgn
> 
> Hi Sheng,
> 
> > -----Original Message-----
> > From: Sheng Jiang [mailto:[e-mail]]
> > Sent: Thursday, May 14, 2009 7:12 PM
> > To: Templin, Fred L; 'Brian E Carpenter'
> > Cc: [e-mail]; [e-mail]; Fleischman, Eric; Russert, Steven W; 'Rémi Després'
> > Subject: RE: New Version Notification for draft-jiang-v6ops-incremental-cgn
> >
> > Fred,
> >
> > Thanks for your comments.
> >
> > Although I can agree on you the disadvantages of anycast, anycast has its
> > advantages and suitable scenarios, too. Furthermore, I don't think 6rd
> > depends on anycast. Remi may give us clarification.
> 
> As near as I can tell, the contribution of 6rd is the
> definition of a "stateless" prefix delegation mechanism;
> everything else is just intra-site tunneling, and 6rd
> would do well to look at the ISATAP/VET mechanisms that
> already handle this.

With this said, I'd like to propose something toward Remi.
You will be wanting some way for CPE devices to discover
the ISP's 6rd-relays IPv6 prefix. This can be easily
accommodated by defining a new DHCPv6 option (the
"6rd Prefix Option"?) for which the sole purpose is
to convey a prefix and prefix length.

The CPE device can then use Stateless DHCPv6 to obtain
the prefix from a relay/server in the ISP network via
IPv6/IPv4 tunneling. The address of the relay/server
can be discovered using the PRL discovery mechanisms
of ISATAP [RFC5214].

Thanks - Fred
[e-mail]

>
> Thanks - Fred
> [e-mail]
> 
> > However, our draft does no intend to make judge of 6rd, or other tunnel
> > techonogies. We actually would like to list serveral suitable tunnel
> > techonogies with brief introductions in order to complete our puzzle. As we
> > ready state in the draft, "ISATAP or VET are also be considered." Actually,
> > one thing we can do for next version is to expand this section a little bit,
> > to include brief introductions for Auto GRE, ISATAP and VET. However, we
> > also think 6rd is suitable and do not want to rule it out.
> >
> > Best regards,
> >
> > Sheng
> >
> > > -----Original Message-----
> > > From: Templin, Fred L [mailto:[e-mail]]
> > > Sent: Friday, May 15, 2009 7:02 AM
> > > To: Brian E Carpenter
> > > Cc: Sheng Jiang; [e-mail]; [e-mail];
> > > Fleischman, Eric; Russert, Steven W; Rémi Després
> > > Subject: RE: New Version Notification for
> > > draft-jiang-v6ops-incremental-cgn
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Brian E Carpenter [mailto:[e-mail]]
> > > > Sent: Thursday, May 14, 2009 3:50 PM
> > > > To: Templin, Fred L
> > > > Cc: Sheng Jiang; [e-mail]; [e-mail]; Fleischman,
> > > > Eric; Russert, Steven W; Rémi Després
> > > > Subject: Re: New Version Notification for
> > > > draft-jiang-v6ops-incremental-cgn
> > > >
> > > > Fred,
> > > >
> > > > (My previous message was somewhat inscrutable. See in-line.)
> > > >
> > > > 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.
> > >
> > > ISATAP and VET already have answers for that ([RFC5214],
> > > Sections 8.3.2 and 9). If 6rd wants to do the same thing, it
> > > would just be re-inventing the wheel.
> > >
> > > > Personally I think a provisioned unicast address may be better,
> > > > because of your points 1-4.
> > >
> > > Provisioned unicast addresses are already the subject matter
> > > for ISATAP/VET Potential Router List (PRL) initialization. Is
> > > a new spec needed?
> > >
> > > > > 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.
> > >
> > > The CPE needs to learn the provider's IPv6 prefix reserved
> > > for 6rd purposes. Unless there is some form of automated
> > > discovery (e.g., PIOs in RAs), the IPv6 prefix would need to
> > > be manually provisioned.
> > >
> > > > > 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?
> > >
> > > Are we running out of /24s? I really don't know. Do I know
> > > waste when I see it? I think so.
> > >
> > > > > 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.
> > >
> > > But, do you know what the service model will look like
> > > 5-10yrs down the line? (Maybe coexisting wireless broadband
> > > and cable modem?) Do you even know what a SOHO network will
> > > look like 5-10yrs down the line?
> > > PI is as some point going to become attractive to enterprises
> > > of any size - not necessarily just the big ones.
> > >
> > > > > 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.
> > >
> > > Let's just have an awareness about this up front. Then, we
> > > will have to explain to the customers years down the line why
> > > we copped out and gave them a moped when they could have had a 'VET.
> > >
> > > Fred
> > > [e-mail]
> > >
> > > >
> > > > Thanks
> > > >
> > > >      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
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > > >
> > >
> >
>