Remi,
-----Original Message-----
From: Rémi Després [mailto:remi.despres@free.fr]
Sent: Tuesday, May 19, 2009 2:19 AM
To: Templin, Fred L
Cc: Sheng Jiang; v6ops@ops.ietf.org; guoseu@huawei.com; brian.e.carpenter@gmail.com; Fleischman,
Eric; Russert, Steven W
Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn
Templin, Fred L - le (m/j/a) 5/14/09 5:17 PM:
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.
As explained in the 6rd draft (soon to become an RFC), 6rd solves the
major problem of 6to4: the lack of guarantee that paths exist between
all IPv6 sites and all 6to4 sites, and that these paths have ISP
controlled QoS.
Yes, so is VET soon to become an RFC. But, 6rd is not solving a
6to4 problem with its open relays; it is solving an intra-site
problem with ordinary IPv6 routers just like VET.
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 important point is that the 6rd-relay address MAY be anycast. If
there is only one relay at this address, there is no difference with an
anycast address.
Reasons for permitting anycast are SCALABILITY and AVAILABILITY of the
solution:
Just for the record, ISATAP/VET can use anycast just
the same as for 6rd but chose not to specify it. This
choice was based on deliberations between authors and
working group alike that identified the stated problems.
- if available relays seem to be soon insufficient for the traffic, just
add one more, at the same anycast address. While ISATAP is intra-site,
6rd relays, like those of 6to4 which also use an anycast address, have
to support all the IPv6 traffic of an ISP that uses 6rd.
- if a 6rd-relay fails, the traffic goes to another one.
No; 6rd is intra-site. The site is the ISP operator's
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.
If the ISP supports an IPv4 MTU long enough for IPv6 packets of 1280
octets (as it should) and discards longer ones, no fragmentation is ever
needed.
This is common with 6to4, which uses anycast addressing for its relays.
1280 is an unsatisfactory MTU for customer devices that
would prefer to use 1500. The CPE is an in-the-network
tunnel endpoint such that customer devices on a 1500
segment would be constantly inconvenienced with ICMP
PTB messages were the CPE to deploy with only 1280.
But, if you want to push the CPE tunnel endpoint to
1500, you have to allow for the possibility of
fragmentation. VET and SEAL solve this problem.
2) with anycast, there is no opportunity for default
router selection (when there are multiple)
Yes. But what is the practical problem?
If there are multiple PE routers in the ISP network,
the CPE should have the ability to distinguish them
and choose between them - just as for any link where
there may be multiple routers.
3) with anycast, there is no opportunity for traffic
engineering
Different source zones may be oriented toward different relays, or relay
farms with internal load balancers.
Traffic engineering is the ability for a CPE router
to direct some traffic through PE router A and other
traffic through PE router B. With anycast, the CPE
router can't discern A from B.
All the complexity of deciding which customer sites should receive which
unicast addresses is avoided.
I don't see anything having to do with complexity, really.
And, it's the very same consideration as to which customers
should receive which DNS suffixes.
4) with anycast, IPv6 neighbor discovery over the
tunnel may yield unpredictable results
Neighbor discovery doesn't apply more over 6rd tunnels than it does on
6to4 tunnels.
Neighbor discovery is useful in many ways. NUD, default
router preferences and more specific routes, SEND, and
many more. 6rd is not really comparable to 6to4, however;
6rd is intra-site just as ISATAP/VET.
5) with anycast, there is need for a manual provisioning
of IPv6 prefixes and IPv4 anycast address on the CPE
router.
As explained in the draft, Free deployed 6rd with their 6rd parameters
included in their downloaded CPE software (IPv6 prefix and relay anycast
address).
This is unnecessarily marrying the CPE devices to the
ISP in a way that CPE vendors might not appreciate. It
also makes renumbering and discovery of new prefixes
quite cumbersome.
For independently supplied CPEs , tools to convey these parameters have
to be specified. As far as I know, Mark Townsley is working on a
proposal for this.
If Mark Townsley is working on a proposal for this, he is
re-inventing ISATAP PRL discovery. See also my proposal
for stateless DHCP prefix delegation for the 6rd prefix.
Fred
fred.l.templin@boeing.com
Regards,
RD