Subject: Fwd: (ngtrans) 6to4anycast fineshes last call, ready for IESG forwarding as PS

From: Bob Fink <[email-masked]>
Date: Wed, 10 Jan 2001 08:56:45 -0800

Randy,

Having heard nothing from the list on 6to4anycast-00 and the changes 
Christian added to respond to last call comments, I am submitting it to you 
for IESG processing.

Thanks,

Bob

======================================
>Date: Mon, 08 Jan 2001 12:22:22 -0800
>To: NGtrans List <[email-masked]>
>From: Bob Fink <[email-masked]>
>Subject: (ngtrans) 6to4anycast fineshes last call, ready for IESG 
>forwarding as PS
>Cc: Christian Huitema <[email-masked]>,
>         Alain Durand <[email-masked]>, Tony Hain <[email-masked]>,
>         Randy Bush <[email-masked]>
>Sender: [email-masked]
>Reply-To: Bob Fink <[email-masked]>
>
>NGtrans Folk:
>
>Christian's 6to4 anycast draft passed wg last call for IESG forwarding (as 
>PS) with two minor comments (Bradner's comment repreated below, and 
>Moore's which appeared on the ngtrans list) which he has addressed in his 
>personal draft -01, which is now entered as ngtrans draft -00:
>
><http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4anycast-00.txt>
>
>
>I will forward this new version to the IESG Wednesday, so please ask 
>Christian any questions you may have about this new draft.
>
>
>Thanks,
>
>Bob
>
>===
>From: Scott Bradner <[email-masked]>
>Message-Id: <[email-masked]>
>
>... you should not ask for a specific
>length assignemnt - you should point out that you need addresses that
>will pass through the prefix filters that ISPs have and let the IANA/RIRs
>figure out what specific addresses to provide (they have swamp space
>for example which is in the form of /24s)
>...
>===
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Jan 2001 14:50:14 -0500

Bob,

I must have misunderstood. 

I interpreted your last message ("please ask Christian any questions
you may have about this new draft") to mean that you were closing 
WG discussion of this draft as of last Monday (because you didn't
say "submit comments to the list").  

I do have some objections to the new text in section 5.6:

1. IIRC at the last IETF meeting Tony claimed that his scheme for doing 
   RD/ND was compatible with Christian's proposal, but the wording in 
   the latest version of this document appears to nix that possibility.  
   I thought we had agreed to at least leave the possibility open, 
   rather than closing the door.

   If we later decide that ND or RD is a good idea I don't want us 
   to have to ask for another prefix.

2.  as for the text itself:

> The ND alternative would be to use the anycast address for
> discovering the nearest relay, and then to build a "regular"
> association with this relay. It can be argued that using ND will be
> more a more standard way to do routing, that with a regular
> association failures will be easier to detect, and also that nailing
> the default connection to a specific 6to4 relay router will avoid
> any transient failure caused by the routing protocol. On the other
> hand, there are many arguments against this type of association.

the principal reason that I saw for using ND/RD (or a variant thereof)
is that packets destined for a native IPv6 subnet could be tunneled 
directly to the IPv4 address of a router that was acting as a tunnel
endpoint for that subnet, without having to tunnel all non-6to4 packets 
to a single relay router.  this would reduce the load on relay routers.

in other words, I wasn't viewing ND as a mechanism for finding
a single relay router but was viewing RD as a mechanism for finding
a tunnel endpoint for a specific subnet.  the tunnel endpoints
could be propagated using MP-BGP, perhaps using the same mechanism
as suggested in draft-ietf-ngtrans-bgp-tunnel-00.txt.

> Using ND to discover the next hop router may be in line with the
> generic IPv6 architecture, but is actually not in line with the
> specific software written for 6to4, in which the IPv4 next hop is
> derived algorithmically from the IPv6 destination address. 

this is only the case for 6to4 destination addresses, not for other
destination addresses.

> In any
> case, maintaining ND associations for each 6to4 router that they
> serve will increase the load of 6to4 relay routers.

I might need to read the ND spec again, but from what I remember, I
disagree.  I see no need for the relay routers to maintain per-client
state.  And if the relay routers were able to redirect some traffic
directly to an appropriate tunnel endpoint, it would lessen their
overall load rather than increase it.

> If the default connection is nailed to a specific 6to4 relay router,
> the 6to4 router must actively monitor that router, detect failures,
> and then try to find a secondary router, which will only be possible
> if routing tables have been updated.  

Well of course it assumed that relay routers will update their routing
tables so that they can return RA replies based on current information.
But given that all of these RA replies are expressing tunnel endpoints
in terms of IPv4 addresses, what's wrong with having each RD request
stand on its own?

> In contrast, with a pure
> anycast tunnelling solution, the packets will be routed to the
> functioning 6to4 relay router as soon as the routing tables have
> been updated.

granted, the RAs would need relatively short TTLs.

> After a failure of the nearest 6to4 relay router, if we use ND, the
> default connection will be nailed to a back-up 6to4 relay router,
> and will only be nailed back to the nearest 6to4 relay router if the
> back-up fails. 

The connections don't get nailed to relay routers (or tunnel endpoints)
for any longer than the TTLs in the RA messages.  

> In contrast, with a pure anycast tunnelling solution,
> the packets will always be routed to the nearest available 6to4
> relay router.

right, but at the expense of having all non-6to4 traffic tunneled 
through those relay routers.

it seems to me that which one is better really depends on your 
model for deploying relay routers (do you want to deploy a few
relay routers or are you willing to deploy lots of them and disperse
them throughout your net?),  and your assumptions about how many 
of the native v6 subnets will be willing to advertise suitable tunnel 
endpoints.

> Another line of argument is that the use of ND between routers is
> not entirely defined, and that using ND in this scenario is
> potentially more complex and more error-prone than just forwarding
> the packets to a well-known anycast address. In the absence of a
> clear-cut advantage for the ND solution, it is preferable to chose
> the simpler alternative, pure anycast tunnelling.

I agree with the argument that ND is more complex, but didn't think
we had consensus to close the door on using it.

Keith

---

From: Bob Fink <[email-masked]>
Date: Wed, 10 Jan 2001 16:52:11 -0800

Randy,

Shall we consider Keith's comment as part of the IESG review, or do you 
want it resolved by ngtrans before you folk consider it?

Bob

===