Subject: Re: (ngtrans) RE: v6[v4] address in ngtrans-bgp-tunnel

From: [email-masked]
Date: Fri, 24 Aug 2001 09:37:50 +0200

see comments below
g

Alain Durand <[email-masked]> on 23/08/2001 23:01:20

  To:          [email-masked]                          
                                                              
  cc:          [email-masked],                 
               [email-masked], Gerard                     
               GASTAUD/FR/ALCATEL@ALCATEL,                    
               [email-masked],                     
               [email-masked], Dirk              
               OOMS/BE/ALCATEL@ALCATEL,                       
               [email-masked], [email-masked],     
               Jeremy DE CLERCQ/BE/ALCATEL@ALCATEL,           
               [email-masked]                       

  Subject      Re: (ngtrans) RE: v6[v4] address in            
  :            ngtrans-bgp-tunnel                             

[email-masked] wrote:

> > Also, because we're telling people they no longer need to implement
> > auto-tunneling using v4-compatible addresses.
> I'm sorry I still don't understand why your telling people not to implement
> auto-tunnelling when it's probably in every implementation today.
> It seems like your saying OK we specified this feature, it gets implemented
> and now we shall remove it.  Is it me, as this doesn't make sense?
>
> Is this the way RFC's usually evolve?
>
> Stuart

Automatic tunneling has been around for a long time, and until now
has had very little usage.
Very early in the 6bone days, we realised that this form of tunneling was
not very usefull as it could only link two machines that already had IPv4
addresses in the same realm (both local or global) and that those
addresses could not be used by a third party.
E.g. if A & B used IPv4 compatible addresses and B passes A's address to C
and C does not implement automatic tunnels, C could not reach A easily.
This is the reason why we are using global addresses, with either manual
tunnels or automatic tunnels a la 6to4, 6over4 or more recently isatap,
which can supersede both 6over4 and IPv4 compatible addresses.
>>> in BGP cases, we deal with routers

Also, IPv4 compatible addresses have introduced a lot of confusion
to IPv6 beginner as their syntax and definition is close to IPv4 mapped
addresses, but their semantic is very different.
>>>> could it be the revere? mapped address came after the v4 compatible ?

As there is very little use of IPv4 compatible addresses, very little gain to
expect
from them, some confusion around them and an existing solution to replace them,

we are thinking of deprecating them.
>>> is there a survey done on their usage to back up this statement? it could help

They are defined in RFC2893 which is at Proposed Standard level and supersede
RFC1933 also at PS level. We would like to update RFC2893 and move it to
Draft Standard, and yes, it is usual to drop some feature when moving a
document to DS.

I understand that this would be a problem for the BGP-tunnel draft if there
were
no alternatives, but from the discussions I see on this list, it does not seem
to
be case.
>>> it seems that the alternatives are v4 compatible, mapped, isatap and every one of them works for the bgp tunnel: so may be we should just list them and let operators decide for their own domain assuming that v4 compatible feature will remain in most
routers (to be checked). IN fact, isatap is likeky not uet in routers so I see a case for v4 compatible use now, and later mapped or ISATAP..

    - Alain.

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 24 Aug 2001 15:22:34 +0200

Gerard and all,

At 09:37 24/08/2001 +0200, [email-masked] wrote:

> >>> it seems that the alternatives are v4 compatible, mapped, isatap and 
> every one of them works for the bgp tunnel: so may be we should just list 
> them and let operators decide for their own domain assuming that v4 
> compatible feature will remain in most
>routers (to be checked). IN fact, isatap is likeky not uet in routers so I 
>see a case for v4 compatible use now, and later mapped or ISATAP..
>
>     - Alain.

I would recommend that we do select one single address format for the 
bgp-tunnel draft rather than allowing multiple formats. Allowing multiple 
formats:
         - does not give anything useful to the network operator since this 
v6 address is never visible (only appears inside a BGP message and the only 
meaningful info is the v4 address carried inside)
         - forces the operator to make a choice for something irrelevant to 
him/her and to configure yet another knob
         - adds an opportunity for intereoperability problem

I also reiterate my vote for IPv4-mapped as the format to be used in 
bgp-tunnel:
         - no technical issue with it (ie does the job, allows private 
where prefered ,...)
         - definition matches excatly what we're using it for

Cheers

Francois
_______________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 89 108 159
Fax:                   +33 4 97 23 26 26
Email:                  [email-masked]
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
Bâtiment T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________

---

From: Alain Durand <[email-masked]>
Date: Fri, 24 Aug 2001 11:34:23 -0700

>          - adds an opportunity for intereoperability problem

I would agree with this analysis, defining only one format is preferable.

There is one point that is not very clear to me:
In the BGT-tunnel scheme, can the Next Hop address be passed in any manner
to another BGP speaker?

If it is the case, then shouldn't this address be reachable by this 3rd
BGP speaker?

    - Alain.

---

From: Dirk Ooms <[email-masked]>
Date: Tue, 28 Aug 2001 10:33:23 +0200

see below

> I would agree with this analysis, defining only one format is preferable.

I also agree with the above, which leaves us with the choice between
isatap or v4-mapped (draft-ietf-ipngwg-addr-arch-v3.txt indeed relaxes
the defintion of v4-mapped compared to rfc2373, but there is still the
issue of being globally routable).

Maybe isatap is the best choice because of its flexibility to set the
scope of the address.

> In the BGT-tunnel scheme, can the Next Hop address be passed in any manner

Alain: can you elaborate on your question?

dirk

---

From: Alain Durand <[email-masked]>
Date: Tue, 28 Aug 2001 16:29:38 -0700

> Alain: can you elaborate on your question?

RFC2545:

   IPv6 defines 3 unicast address scopes [ADDR-ARCH]: global, site-local
   and link-local. Site-local addresses are non-link-local address which
   are valid within the scope of a "site" and cannot be exported beyond
   it. As this document makes no assumption on the characteristics of a
   particular routing realm where BGP-4 is used, it makes no distinction
   between global and site-local addresses and refers to both as
   "global" or "non-link-local". Network administrators must however
   respect address scope restrictions and should be aware that the
   concepts of a BGP-4 routing domain and "site" are orthogonal notions
   and that they may or may not coincide in a given situation.

   Companion IPv6 specifications further define that only link-local
   address can be used when generating ICMP Redirect Messages [ND] and
   as next hop addresses in some routing protocols (eg. RIPng [RIP]).

   This restrictions does imply that an IPv6 router must have a link-
   local next hop address for all directly connected routes (routes for
   which the given router and the next hop router share a common subnet
   prefix).

   Link-local addresses are not, however, well suited to be used as next
   hop attributes in BGP-4 given the rules defined for this attribute in
   the protocol specification [BGP-4].

   For the above reasons, when BGP-4 is used to convey IPv6 reachability
   information it is sometimes necessary to announce a next hop
   attribute that consists of a global address and a link-local address.
   The following section describes the rules that should be followed
   when constructing the Network Address of Next Hop field of an
   MP_REACH_NLRI attribute.

3. Constructing the Next Hop field

   A BGP speaker shall advertise to its peer in the Network Address of
   Next Hop field the global IPv6 address of the next hop, potentially
   followed by the link-local IPv6 address of the next hop.

   The value of the Length of Next Hop Network Address field on a
   MP_REACH_NLRI attribute shall be set to 16, when only a global
   address is present, or 32 if a link-local address is also included in
   the Next Hop field.

   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
   of Next Hop field and the peer the route is being advertised to.
   In all other cases a BGP speaker shall advertise to its peer in the
   Network Address field only the global IPv6 address of the next hop
   (the value of the Length of Network Address of Next Hop field shall
   be set to 16).

   As a consequence, a BGP speaker that advertises a route to an
   internal peer may modify the Network Address of Next Hop field by
   removing the link-local IPv6 address of the next hop.

=> So it could make sense for the Next Hop field to use the global address
      of the router plus the isatap derived one in the fe80::/10 prefix.

---

From: Dirk Ooms <[email-masked]>
Date: Wed, 29 Aug 2001 10:31:31 +0200

Alain,

Your quote from rfc2545 says "The link-local address shall be included
in the Next Hop field if and only if the BGP speaker shares a common
subnet with the entity of Next Hop field and the peer the route is being
advertised to".  My impression is that this does not apply to the
bgp-tunnel scheme since the bgp-tunnel advertisement is typically iBGP
going over an IPv4 network, so the BGP peers won't have a common IPv6
subnet (unless one would consider IPv6 neighbours connected by a tunnel
as 'having a common subnet').

I'm not feeling very confident about the above, so a reaction of a BGP
guru would be nice.

dirk

-- 
Dirk Ooms                       mailto:[email-masked]
                                tel:+32 3 2404732
Network Strategy Group (NSG)    http://aww.alcatel.com/nsg
Alcatel                         http://www.alcatel.com

---

From: Alain Durand <[email-masked]>
Date: Wed, 29 Aug 2001 10:43:05 -0700

>as 'having a common subnet').

You can model BGP tunnels as a collection of BGP peers
that share the same layer 2 link, here this link happen to be the IPv4 
Internet.
Then,  it becomes possible to picture a subnet that span among
all those routers (a la LAN Emulated). This is exactly what ISATAP
will give you. And as you do not need a global address for this subnet,
and all you need are link local addresses, as Dave Thaler said before,
all you need is the prefix fe80::/10, expand it to fe80::/64
and put an ISATAP generated EUI64 in the lower 64 bits.

         - Alain.