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

From: [email-masked]
Date: Thu, 23 Aug 2001 11:02:33 +0100

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]]
> Sent: 22 August 2001 23:51
> To: stuart.prevost; flefauch; Gerard.Gastaud
> Cc: Erik.Nordmark; ngtrans; dirk.ooms; tonyhain; deering;
> jeremy.de_clercq; tri.t.nguyen
> Subject: RE: (ngtrans) RE: v6[v4] address in ngtrans-bgp-tunnel
> 
> 
> Stuart Prevost asks:
> > If someone can tell me what exactly is the problem with 
> > keeping IPv4-compatible IPv6 address then please do.
> 
> Because the draft requires the ability to use private
> IPv4 addresses, and the RFC is being updated to clarify
> that v4-compatible addresses cannot use private IPv4 addresses.
The draft does not require the ability to use private addresses, it can use
global addresses.  It just that if you implement this is an Intranet you can
use either, depending on your network design.

> 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
> -Dave

---

From: Alain Durand <[email-masked]>
Date: Thu, 23 Aug 2001 14:01:20 -0700

> Is this the way RFC's usually evolve?

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.

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.

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.

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.

    - Alain.