Subject: (ngtrans) Re: I-D ACTION:draft-templin-ngtrans-v6v4compat-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Apr 2000 11:55:44 -0500

Hi Fred,

An interesting draft. I'm not sure that I know yet whether I like it or
hate it :-)

The "hate" issue is whether the notion of triggering automatic encapsulation
has dangers (security, routing loops, etc.). Looking into the ID field to 
trigger encapsulation is a kludge, and we have to decide if it's one we 
can live with. I think you need to do what we did for 6to4: 
write out the sending rule, and draw diagrams of various secenarios,
to understand what is really going on.

The notion of translating the ID in the gateway is definitely a no-no.
We aren't allowed to break the end to end model with IPv6 since we rely on
it for IPSEC, and we mandate IPSEC for IPv6. 

You may have noticed in the latest version of 6to4 that we deprecate using
Net 10 addresses to generate a 6to4 prefix, but I think the idea of using
them (tagged "local") to generate a host ID is probably safe. It is also vital,
since the fundamental objection to your scheme is that we don't have enough
unique IPv4 addresses anyway, so they are no good as unique identifiers.

Given that, I see your scheme and 6to4 as potentially complementary.

Unfortunately the text on multicast in 6to4 that you cite turns out to
be rubbish. It will be removed from the next version of the 6to4 draft,
and a separate document has been promised by an expert.

I hope we get a chance to review this at the Pittsburgh IETF, complete
with scenarios.

    Brian Carpenter

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 12 Apr 2000 10:22:53 -0700

Brian,

Thankyou for your initial comments. I'd like to point out that
this work has evolved independently from the 'ngtrans' works, of
which I have only very recently become aware. I have had my head
buried in a project involving a combination of Mobile IP and a
MANET-like micro-mobility routing protocol since about July of
last year and needed to come up with a way of leveraging the
advanced features of Mobile IPv6 from within an heterogeneous
IPv6/IPv4 network. So, I gradually devised the scheme described
in this draft with reference to the IPNG RFC's and by adding
extensions to the INRIA IPv6 implementation under FreeBSD.

When I finally got a chance to catch my breath from the focused
project work about a month ago, I caught my first glimpse of '6to4'
and realized that I had been working in something of a parallel
universe. But, I felt it appropriate to disclose my approach to
the 'ngtrans' group in the case that any of my methods might prove
helpful in the transition to IPv6.

I will take a closer look at your comments and send my responses.
As to reviewing the draft, I have been in communication with the
'ngtrans' working group chairs who have invited me to present
either at the upcoming interim meeting or at the next IETF in
Pittsburgh. I believe the interim meeting will be held in Palo
Alto, CA sometime within the next two months, and this would be
the more convenient timing and location for me. But, I can also
attend Pittsburgh if this would be preferred.

Regards,

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 13 Apr 2000 10:03:44 -0700

Brian,

Sorry for the delay on this. As promised, here are some responses
to your initial comments:

Brian E Carpenter wrote:
> has dangers (security, routing loops, etc.).

I definitely havn't had had enough time to investigate the security
aspects of this fully, but I'm fairly confident there are no new
opportunities for routing loops that didn't previously exist. I will
investigate further for these and other potential pitfalls, however.

> Looking into the ID field to
> can live with.

I didn't percieve any negative connotations from this comment, but I
think I should point out that my encapsulation method derives directly
from either existing standards or proposed extensions to existing
standards that I describe in the draft. So, I don't agree that this
method could be considered a "kludge".

First, the IANA OUI (00-00-5E) is an official assignment from the
IEEE Registration Authority, and the Internet Assigned Numbers
documents describe its standard usage for EUI48-format IEEE 802
addresses. Any other usage of the IANA OUI is in violation of the
current standards.

Secondly, the IEEE has specified a new address format called EUI64
which has been adopted by Internet RFC 2373 for the formation of
interface identifiers. EUI64 additionaly specifies a method for
encapsulating legacy EUI48 addresses within EUI64 addresses; namely,
if the two octets of the EUI64 address immediately following the three
octet OUI are 0xFFFE, then the EUI64 address encapsulates a legacy
EUI48 address. (EUI64 also reserves the value 0xFFFF for the two octets
following the OUI for future use.)

So, at a minimum, software must examine the octet immediately following
the OUI to determine whether the address is in native EUI64 format, or
whether it (potentially) encapsulates a legacy EUI48 address. Finally,
EUI64 implies that, beyond the two "special" encodings described in the
previous paragraph, administrative authourities for individual OUI's
should define an EUI64 addressing architecture specific to the OUI
they administer. My draft proposes one possible EUI64 addressing
architecture for IANA's OUI assignment that simultaneously:

  1) satisfies the EUI64 standard
  2) provides a format for encapsulation of IPv4 addresses
  3) allows maximal expansion for future IANA use

So, if my proposed extensions to support EUI64 addresses under the
IANA OUI are eventually adopted, my method for embedding IPv4
addresses would become a "standard"; not a "kludge".

I know I've already beaten this horse to death, but I feel I should
point out what this means to S/W implementations. In the INRIA
implementation, at least, IPv6 addresses can be accessed as either
16 contiguous octets or 4 contiguous 4-octet integers. To check for
an embedded IPv4 address encapsulated in the method described in
my draft, the INRIA S/W only needs to do a compare of the third
integer in the IPv6 address against the value: 0x02005EFE in
big-endian architectures or: 0xFE5E0002 in little-endian architectures.
So, a single machine instruction tells whether/not the interface
identifier encapsulates an IPv4 address.

One final whimsical thought on this subject is that the 6to4 draft
points out that IPv4 is essentially treated as a virtual link layer;
a concept which I fully agree with. If so, then what better place
to encode the IPv4 address than in the interface identifier portion
of the IPv6 address? (Tounge is in cheek, here...)    

> I think you need to do what we did for 6to4:

I agree with this, and will write out the sending rules as you
suggest before presenting the draft at an upcoming meeting. I believe
the method described in my draft will satisfy most of the same
scenarios as 6to4 (I will verify this), but since it was designed
with Mobile IP and MANET-style routing in mind I believe it may also
address additional scenarios.

For instance, a mobile host with an IPv6-IPv4 compatibility address
constructed in the method described in my draft could leave its home
subnet and keep its EUI64 interface identifier when joining a new
subnet. There, it might learn a new IPv6 routing prefix from router
advertisments and construct a care-of address that is topologically
correct for the new subnet using IPv6 address auto-configuration.
Yet, the interface identifier would still preserve the embedded IPv4
address.  
 
> it for IPSEC, and we mandate IPSEC for IPv6.

OK - thanks for pointing this out.
 
> unique IPv4 addresses anyway, so they are no good as unique identifiers.

OK. My document might seem to imply that these IPv6-IPv4 compatibility
addresses would need to be deployed everywhere (thereby exhausting the
already-exhausted IPv4 address space), but in reality there would only
need to be at most one such address deployed per subnet; other hosts
could use native IPv6 addresses. I will try to make this clearer as
I write up the scenarios.
 
> I hope we get a chance to review this at the Pittsburgh IETF, complete

OK. I'm looking forward to meeting the group and discussing the draft
at an upcoming meeting. Thanks for your comments.

Fred
[email-masked]