Subject: (ngtrans) RE: An IPv4 anycast address for 6to4<->6bone gateways

From: Christian Huitema <[email-masked]>
Date: Mon, 30 Oct 2000 08:47:11 -0800

That, or you incorporate it in the 6to4 draft. What do you prefer?

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, October 30, 2000 8:29 AM
> To: Christian Huitema
> Cc: 'Brad Huntting'; f.johan.beisser; [email-masked];
> [email-masked]
> Subject: Re: An IPv4 anycast address for 6to4<->6bone gateways
> 
> 
> Personally, I'd prefer to re-allocate Net 10 for this :-)
> 
> Yes, this is an interesting approach. Anybody want to write a draft?
> 
> N.B. 6to4 is an NGTRANS work item. I have removed IPNGWG from 
> the copies.
> 
>    Brian
> 
> Christian Huitema wrote:
> > 
> > Actually, what you want is to reserve sufficiently large IP 
> address prefix,
> > so that it will be accepted without questions by BGP 
> routers -- at least a
> > /19; a class B would be nice; in fact, if an address rich 
> institution would
> > donate a class B for that purpose, that would be even 
> better; asking the
> > IANA to reserve 191.255/16 for that purpose would also look 
> cool. It would
> > also be useful to dedicate an IPv4 AS number to that purpose.
> > 
> > The IPv6 routers that have a complete access to both IPv6 
> and IPv4 would
> > announce the corresponding prefix in their local IGP, as a 
> route to an
> > external network. The ASes that run such routers and are 
> willing to provide
> > access to the v6 network would announce a path to the v6 AS 
> and to the 6to4
> > prefix using BGP; they could easily use the existing 
> structure of peering
> > and transit agreement to control to whom they are willing to provide
> > service. The whole v6 network will appear to v4 as a single 
> AS, with lots of
> > peering points all over the place.
> > 
> > The 6to4 gateways would then send use an address under the 
> 6to4 prefix as a
> > default route for reaching v6 packets. It will normally 
> reach the service
> > provided by their ISP, or by the closest ISP according to 
> inter-domain
> > routing.
> > 
> > This scheme has many advantages. It is simple to implement 
> in 6to4 gateways,
> > it allows ISP to control to whom they are providing 
> service, it allows for
> > independent deployments of gateways to the 6Bone and the v6 
> network by
> > multiple ISPs, it allows for scaling by deploying a large 
> number of "peering
> > points."
> > 
> > In the acknowledgement section: I believe that scheme was 
> first proposed by
> > Randy Bush.
> > 
> > -- Christian Huitema
> > 
> > > -----Original Message-----
> > > From: Brad Huntting [mailto:[email-masked]]
> > > Sent: Friday, October 27, 2000 2:46 PM
> > > To: f.johan.beisser
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: An IPv4 anycast address for 6to4<->6bone gateways
> > >
> > >
> > >
> > > > http://www.kfu.com/~nsayer/6to4/
> > >
> > > Actually this web page brings up another issue that a freind and
> > > I were discussing just yesterday.  Anyone who's actually tried to
> > > use 6to4 (2002::/16) has probably noticed that they need a default
> > > route to reach the 6bone.  But even assuming you actually 
> find such
> > > a router it is almost always on the far side of the 
> Internet; which
> > > means that your packets get to take the scenic route on their way
> > > to the 6bone.
> > >
> > > One simple solution to this would seem to be to use a well known
> > > IPv4 "anycast" address (call it "a.b.c.d" for now) for all 6to4
> > > gateways.
> > >
> > > In this way, anyone using 6to4 could reliably use 
> 2002:(a.b.c.d)::1
> > > (actual IPv6 address syntax will vary) as a default route to the
> > > 6bone.
> > >
> > > 6to4 gateways would advertise to the their IPv4 peers that they
> > > have a route for "a.b.c.d".  And for their IPv6 peers (the 6bone)
> > > they can advertise a route for 2002::/16.
> > >
> > > Does anyone see a problem with this?  I dont suppose 
> there's already
> > > a block of IPv4 address space set aside for anycast?
> > >
> > >
> > > brad
> > > 
> --------------------------------------------------------------------
> > > IETF IPng Working Group Mailing List
> > > IPng Home Page:                      
http://playground.sun.com/ipng
> > FTP archive:                      ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to [email-masked]
> > --------------------------------------------------------------------
> >
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Oct 2000 10:07:50 -0600

It needs to be a separate document; the base document is in the RFC Editor queue.

  Brian