|
Here is a list of gross features that moved to Phase II for
the CE Rtr along with justification as to why. Mcast/MLD Proxy – SP feedback told us they don't even
have v4 mcast deployed so they don't want mcast in Phase I.
Further IPv6 transition mechanisms like 6rd, or 6to4 won't be able to
support mcast given the tunnel technology being used by these mechanisms.
DS-Lite mcast is TBD. So we thought why not deal with mcast as task in
Phase II combined with a transition tech that will complicate the state machine
of the CE Router. DNS - people have to discuss DNS Proxy vs. recursive DNS
server to be supported in the CE Router device. Frankly we recommend a
recursive DNS server, but the discussion has to happen within the design team
and then a decision discussed in v6ops. Further DNS64 is recommended in
the CE Rtr device but DNS64 is not in RFC form. ND Proxy - The ND Proxy RFC 4389 is an Experimental RFC that
a v6ops document cannot reference. Therefore a new I-D has
been submitted to 6man today to deal with this issue. See http://www.ietf.org/id/draft-wbeebee-6man-nd-proxy-std-00.txt Prefix sub-delegation - this is clearly some new work TBD in
6man before it can be added to the CE Router doc. Qos, Path MTU - ran out of time before this IETF to put in
Qos for Phase I. Path MTU doesn't have clear solutions and thus didn't make
sense to wrestle with it in Phase I. IPv6 transition mechanisms - clearly being in draft form are
best punted to Phase II. Multiple WAN interfaces – default route selection
problem is an open question. Conceptual configuration variables – may add one or
two in Phase I in -03 version or if not, the complexity of Phase II will add
such variables Managability - SP's have to give more feedback before this
work can be completed. Hemant |