Subject: (ngtrans) working group last call for 6to4-05 forwarding as PS - closes 5 June 2000

From: Bob Fink <[email-masked]>
Date: Sun, 21 May 2000 22:12:04 -0700

NGtrans Folk,

The 6to4-05 draft was published on 18 May to address outstanding issues 
from the -04 draft. The authors believe 6to4 is done, and that it is time 
to last call it for forwarding as a Proposed Standard.

Changes from 04 to 05 version:
- text on multicast largely removed (awaiting separate draft)
- noted that relay routers only accept traffic from specific sites
- clarified that V4ADDR must be configured on an IPv4 interface
- link-local text rewritten
- added note on NUD
- strengthened security text on address filtering
- general text clarifications and response to detail comments

Thus there will be a two-week ngtrans working group last call.

Comments to the list by 5 June 2000.

Thanks,

Bob

 > A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 > This draft is a work item of the Next Generation Transition Working 
Group of the IETF.
 >
 >         Title           : Connection of IPv6 Domains via IPv4 Clouds without
 >                           Explicit Tunnels
 >         Author(s)       : B. Carpenter, K. Moore
 >         Filename        : draft-ietf-ngtrans-6to4-05.txt
 >         Pages           : 22
 >         Date            : 18-May-00
 >
 > This memo specifies an optional mechanism for assigning a unique
 > IPv6 address prefix to any site that currently has at least one
 > globally unique IPv4 address, and describes scenarios for using such
 > a prefix during the co-existence phase of IPv4 to IPv6 transition.
 > Effectively it treats the IPv4 network as a unicast link layer. Note
 > that this is not considered to be a long term solution and that sites
 > should migrate in due course to native IPv6 prefixes.
 > The motivation for this method is to allow isolated IPv6 domains or
 > hosts, attached to an IPv4 network which has no native IPv6 support,
 > to communicate with other such IPv6 domains or hosts with minimal
 > manual configuration. It also automatically provides a globally
 > unique IPv6 address prefix to any site with at least one globally
 > unique IPv4 address, even if combined with an IPv4 Network Address
 > Translator (NAT).
 >
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-05.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 May 2000 08:11:16 -0500

Note that I found two glitches during the weekend: delete the first sentence
of section 3.1, and ignore the large blank space on page 6. These will
be fixed during editing.

   Brian

---

From: Ole Troan <[email-masked]>
Date: 22 May 2000 16:09:25 +0100

"5.2 Mixed scenario with relay to native IPv6

[...]

2. There are two deployment options for a 6to4 exterior routing
   domain:

   2.1 No IPv6 exterior routing protocol is used. The 6to4 routers using
   a given relay router each have a default IPv6 route pointing to the
   relay router. The relay router MAY apply source address based filters
   to accept traffic only from  specific 6to4 routers.

   2.2 An IPv6 exterior routing protocol is used. The set of 6to4
   routers using a given relay router obtain native IPv6 routes from the
   relay router using a routing protocol such as BGP4+ [RFC 2283,
   BGP4+]. The relay router will advertise whatever native IPv6 routing
   prefixes are appropriate on its 6to4 pseudo-interface. These prefixes
   will indicate the regions of native IPv6 topology that the relay
   router is willing to relay to. Their choice is a matter of routing
   policy. It is necessary for network operators to carefully consider
   desirable traffic patterns and topology when choosing the scope of
   such routing advertisements. The relay router will establish BGP
   peering only with specific 6to4 routers whose traffic it is willing
   to accept.

   Although this solution is more complex, it provides effective access
   control, i.e. BGP4+ policy controls which 6to4 routers are able to
   use which relay router.
"

I don't understand how BGP policies can be used for access control. any
6to4 router can point a default route to any relay router, as long as
the relay's 6to4 address is known. BGP shouldn't matter.
the only way to provide access control is by using filters.

I'm not particularly fond of the idea of announcing just "appropriate
prefixes" to the 6to4 domain. this would lead to the situation where
the 6to4 site could only reach some parts of the IPv6 Internet.
a 6to4 site needs at least one relay which provides a default route,
or a full routing table.

/ot

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 May 2000 13:48:16 -0500

See below...

> the only way to provide access control is by using filters.

Perhaps "access control" is the wrong phrase. BGP policy will control
which regions of IPv6 space are accessed via which relay router, as in
the first diagram in section 5.4. That's just bog standard BGP.

> a 6to4 site needs at least one relay which provides a default route,

Very likely, but that is a matter of service provider policy, not something
that the IETF decides. Again, bog standard BGP.

    Brian