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

From: [email-masked]
Date: Wed, 22 Aug 2001 16:55:38 +0100

Francois,

We have two issues here, from my practical point of view bgp-tunnel works
today using auto-tunnel mode.  Auto tunnel mode uses IPv4-compatible IPv6
addresses.  If change the draft to use IPv4-mapped IPv6 addresses then
auto-tunnel mode breaks in current implementations.  I know this as we just
tried it on the network.  I agree in theory that it would work, if
implementations are changed.

Not being a regular attendee of IETF meetings etc..  I see this

IETF defines IPv4-compatible IPv6 addresses
Auto tunnel (IPv4-comaptibe IPv6 addresses) is implemented very early in
IPv6 life.
draft-ietf-ngtran-bgp-tunnel-02.txt is written that makes use of
IPv4-compatible IPv6 addresses (auto-tunnel)
Discussion on removing IPv4-comptible IPv6 address!!!

We then have to change draft (not really a problem)
Router manufacturers have to reflect changes in draft in there
implementations (take time).

I don't have a problem with the addresses being changed to IPv4-mapped IPv6
address, my question is do we really need to remove IPv4-compatible IPv6
addresses?

Please forgive me if I don't fully understand all the issues, but it seems
like the goal posts are moving, and I don't think it is necessary.

If someone can tell me what exactly is the problem with keeping
IPv4-compatible IPv6 address then please do.

Regards,
Stuart

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: 22 August 2001 14:46
> To: [email-masked]
> Cc: Erik Nordmark; [email-masked]; Dave Thaler;
> [email-masked]; Tony Hain; Erik Nordmark; Steve Deering;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: v6[v4] address in ngtrans-bgp-tunnel
> 
> 
> Hi,
> 
> I'd like to support Erik's argument in favor of selecting 
> "IPv4-mapped IPv6 
> address" for ngtrans-bgp-tunnel.
> 
> My perception is that:
>          - "IPv4-mapped IPv6 address" are defined exactly for 
> the purpose 
> of conveying an IPv4 address in an IPv6 address format, which 
> is precisely 
> what we need to do in ngtrans-bgp-tunnel (for memory what we 
> want to do is 
> convey the IPv4 address of the BGP Next Hop inside a BGP 
> advertsiement, but 
> purely because of BGP encoding restrictions we are forced to 
> convey it as 
> an IPv6 address)
>          - draft-ietf-ipngwg-addr-arch-v3-06.txt has already 
> carefully 
> replaced the term "IPv4-only" (which was used in RFC2373) by 
> "IPv4" so 
> there is no problem with current definition with the fact 
> that the BGP 
> router is dual-stack.
>          - as Erik said, there does not seem to be any issue 
> specific to 
> IPv4-mapped address relating to the use of a private IPv4 
> address. If you 
> use a private IPv4 address in an "IPv4-mapped address", then 
> obviously the 
> IPv4 address you convey is not globally routable, but that's 
> what you've 
> decided to do; note that in ngtrans-bgp-tunnel, the "IPV4-mapped IPv6 
> address" itself is not used as a destination address of a v6 
> packet, so 
> routers are not trying to route on it. Again, it is just used 
> to carry the 
> v4 address of a BGP Next Hop inside a BGP v6 advertisement in 
> a format that 
> does not break BGP encoding rules.
> 
> So, to me, the bottom line is:
>          (i) current definition of "v4-mapped" exactly 
> matches what we need
>          (ii) I have not seen any technical issue in using those.
> 
> Am I missing something?
> 
> Thanks
> 
> Francois
> 
> 
> At 12:14 21/08/2001 +0200, [email-masked] wrote:
> 
> 
> >I guess you are right for ngtrans list discussion
> >I refer to draft-ietf-ipng-addr-arc-v3.06; it refers to 
> RFC1933 for a case 
> >of use of v4 compatible addresses., BGP tunnel culd be another one
> >I am not trying to be legalistic, but the wording IPv4 nodes can be 
> >ambiguous: RFC1933 defines it as an IPv4 only or an 
> IPv6/IPv4 node but the 
> >addressing ID does not clearly refer to that definition IMHO. So, 
> >somewhere, this should be made clear in the
> >addressing ID. Without the legalistic approach,I agree that mapped 
> >addresses could be used as well
> >gérard
> >
> >
> >
> >
> >
> >Erik Nordmark <[email-masked]> on 21/08/2001 10:24:47
> >
> >Please respond to Erik Nordmark <[email-masked]>
> >
> >
> >
> >   To:          Gerard GASTAUD/FR/ALCATEL@ALCATEL
> >
> >   cc:          Dave Thaler <[email-masked]>,
> >                Dirk OOMS/BE/ALCATEL@ALCATEL, Tony Hain
> >                <[email-masked]>, Erik Nordmark
> >                <[email-masked]>, Steve Deering
> >                <[email-masked]>, Jeremy DE
> >                CLERCQ/BE/ALCATEL@ALCATEL,
> >                [email-masked],
> >                [email-masked], [email-masked]
> >
> >
> >
> >   Subject      RE: v6[v4] address in ngtrans-bgp-tunnel
> >   :
> >
> >
> >
> >
> >
> >
> >
> >Folks, how about moving this discussion to the ngtrans list 
> so that others
> >can chime in?
> >
> > > My recollection of the interim meeting in 
> Redmond/Washington is that v 4
> > > compatible addresses will not be removed from the 
> addressing ID, and I made
> > > a remark to this effect. I believe this does not preclude 
> removing 
> > their use
> > > in RFC2373 as talked about in London without objection.
> >
> >I'm confused - isn't what you call "addressing ID" the 
> update to RFC 2373?
> >
> > > Thes addresses
> > > required global Ipv4 addresses. Their use is perfectly 
> legal, and if 
> > routers
> > > suport them as mentioned in a previous mail, there is 
> nothing wrong with
> > > this option.
> >
> >The language in draft-ietf-ipngwg-addr-arch-v3 for these 
> addresses explicitly
> >refer to the tunneling described in [TRANS]. Thus I don't come to
> >the conclusion that they can be used in other contexts.
> >
> > > To use mapped address for BGP tunneling, one needs as a minimum
> > > to modify their definition in the address draft and in 
> RFC 2373  since they
> > > represent for BGP tunneling dual stack routers as 
> mentioned in a previous
> > > mail.
> >
> >You seem to be interpreting things differently than I do.
> >Should we embark on a legalistic interpretation of the draft?
> >The sentence says:
> >    A second type of IPv6 address which holds an embedded global IPv4
> >    address is also defined.  This address type is used to 
> represent the
> >    addresses of IPv4 nodes as IPv6 addresses.  This type of 
> address is
> >    termed an "IPv4-mapped IPv6 address" and has the format:
> >
> >To me, clearly an IPv4 node can also be an IPv6 node.
> >If it had said "IPv4-only node (can not have IPv6 support)" I'd agree
> >with you but that isn't what the document says.
> >
> > > They require too global IPv4 addresses.
> >
> >That isn't what section 2.5.5 says in draft-ietf-ipngwg-addr-arch-v3.
> >
> >So, ignoring the legalistic interpretation of the specs, are
> >there technical reasons why you think IPv4-mapped address 
> will not work?
> >
> >   Erik
> >
> >
> > > But it  is likely that inside
> > > an AS, the IPv4 address of a BGP border router would be a 
> global one (?).
> > > ISATAP format is define in Fred's ID which states that 
> the format could be
> > > used for other purposes than ISATAP. This format is not 
> yet included in the
> > > addressing ID. ISATAP for its own purposes, mandates to 
> use any globally
> > > aggregatable 64-bit IPv6 routing prefix (whether from a  
> native IPv6
> > > assigned numbers authority or from a special-purpose 
> numbering  scheme such
> > > as [6BONE][6TO4]) reserved by a local network administrator 
> > specifically for
> > > ISATAP purposes (native addresses must not be configured 
> with an ISATAP 
> > PF).
> > > The embedded IPv4 s address can be private or public 
> depending on the site
> > > numbering scheme. For BGP tunnel, it is likely that 
> global address would be
> > > used in the AS. I believe that when this format is included in the
> > > addressing ID, there will be no reference to the use of 
> the prefix by 
> > ISATAP
> > > which is defined in the ISATAP ID and may be in BGP 
> tunnel. I am not 
> > sure we
> > > need a prefix per island, but the prefix should be 
> meaningful in the AS 
> > site
> > > and as such should be configured in the border routers. 
> As mentioned
> > > elsewhere, a site prefix could be used fec0::/ assuming 
> MP-BGP does not
> > > mandate that this address is globally routable
> > > So, my opinion is: compatible addresses or isatap format. 
> If BGP tunnel is
> > > the only remaining ID to use compatible addresses or H/R 
> don't use it
> > > anymore, then I would vote for use of ISATAP. gérard
> > >
> > >
> > >
> > >
> > >
> > > "Dave Thaler" <[email-masked]> on 
> 17/08/2001 19:57:52
> > >
> > >
> > >
> > >   To:          Dirk OOMS/BE/ALCATEL@ALCATEL, "Tony Hain"
> > >                <[email-masked]>, "Erik Nordmark"
> > >                <[email-masked]>, "Steve Deering"
> > >                <[email-masked]>, Jeremy DE
> > >                CLERCQ/BE/ALCATEL@ALCATEL, Gerard
> > >                GASTAUD/FR/ALCATEL@ALCATEL,
> > >                [email-masked],
> > >                [email-masked], [email-masked]
> > >
> > >   cc:
> > >
> > >
> > >
> > >   Subject      RE: v6[v4] address in ngtrans-bgp-tunnel
> > >   :
> > >
> > >
> > >
> > >
> > >
> 
> _______________________
> 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: Erik Nordmark <[email-masked]>
Date: Thu, 23 Aug 2001 10:31:55 +0200 (CEST)

> implementations are changed.

I'm a bit confused.

I thought the issue was just how to communicate a BGP next hop
which is an IPv4 address, and that the BGP speaker would know how to
process this (create a configured tunnel corresponding for anything
using that nexthop).

You seem to say that the BGP speaker would use the automatic tunneling
feature described in RFC 2893 without any modifications to the router.
Is my understanding correct?

I don't think the latter works. For instance, RFC 2893 says that packets
received over an automatic tunnel must not be forwarded futher.

  Erik