Hi Ole, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Ole Troan > Sent: Thursday, February 04, 2010 3:53 AM > To: SanthoshReddyY 71702 > Cc: [email protected]; [email protected] > Subject: Re: [Softwires] Fwd: I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt > > Santosh, > > > We are considering Service Provider gateway (6RD gateway) should directly > > connected to IPv6 > internet. > > [In this case, using ISATAP also we can achieve same] > > > > If SP gateway is not directly connected to IPv6 internet (when we are using > > ISATAP), we can use > ISATAP with manual tunnel. > > I want to point out comparision between 6RD and ISATAP applicability. > > you can of course connect the 6rd BR to the IPv6 Internet any way imaginable > just as you can with an > ISATAP router. > > > Is there any deployment advantages in 6RD over ISATAP ? (Please clarify) > > ISATAP (and 6over4) are tunnel mechanisms which create a virtual Ethernet > connecting isolated hosts. > > 6rd (and 6to4) are tunnel mechanisms which allow isolated _sites_ to connect > to each other. > > one is within an organisation, the other is between organisations. > > 6rd implicitly does prefix delegation. ISATAP does SLAAC as a part of a > shared /64. > > very different deployment scenarios. (of course where things start to blend > together is if you chose > to use one of them just for transport, e.g ISATAP or 6to4 and then used DHCP > PD on top of that, with > native prefixes.)
You are talking here only about the "letter of the law" of RFC5214. But, the applicability statement also says: "Extensions to the above domain of applicability (e.g., by combining the mechanisms in this document with those in other technical specifications) are out of the scope of this document." Those "extensions" have been in the works since before RFC5214 (and indeed even its predecessor RFC4214) were published. The extensions are now culminating in a specification known as VET, which extends the "basic" ISATAP functionality by also allowing for router-to- router tunneling. That makes VET a candidate for the ISP scenario use case the same as for 6rd, where VET can use either DHCP PD or PI delegated prefixes. But if there is sufficient interest, VET can also be easily extended to support the stateless PD feature of 6rd. Thanks - Fred [email protected] > Best regards, > Ole > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
