Subject: [BEHAVE] draft-ietf-behave-address-format-00

From: Rémi Després <[email-masked]>
Date: Tue, 1 Sep 2009 18:29:21 +0200

Christian,

1.
The draft says in its sec. 2.1.5.3:

    The use of a prefix length longer than 64 bits may affect the
    Interface Identifier format.  Specifically, [RFC4291] section 2.5.1
    requires that for all unicast addresses, except those that start  
with
    the binary value 000, Interface IDs are required to be 64 bits long
    and to be constructed in Modified EUI-64 format.  While any method
    can be used to construct a Modified EUI-64, the format requires the
    71st bit (the universal/local bit) to be set with specific meaning,
    and hence it is not available for use by an address format unless  
the
    prefix starts with binary 000.

Here is a text that, without changing the conclusion, would in my  
understanding better reflect points that were made.

[RFC4291] section 2.5.1 imposes that "for all unicast addresses,  
except those that start with the binary value 000, Interface IDs  
(IIDs) are required to be 64 bits long and to be constructed in  
Modified EUI-64 format". In the case of an IPv6 address used to  
represent an IPv4 host, its 64 lower bits are never used to identify  
an interface on an IPv6 link. These lower bits are therefore not  
concerned with the semantics of IIDs. The IID format requirement has  
no technical reason to apply. However, to avoid that a discussion  
involving interpretation of [RFC 4291 ]could delay progress of the  
present draft, where specified address formats are urgently needed,  
all formats defined here comply with the Modified EUI-64  
specification: the 71st bit of IPv6 addresses (the universal/local  
bit) has its meaning defined in [RFC 4291 ].

2.
To qualify IPv6 Addresses, what about replacing "Used to Represent  
IPv4 Hosts" (rather long), by "IPv4-mappable" (shorter, not used yet,  
reasonably intuitive)?

Regards,
RD

---

From: Dave Thaler <[email-masked]>
Date: Tue, 1 Sep 2009 17:11:44 +0000

> IPv4 Hosts" (rather long), by "IPv4-mappable" (shorter, not used yet,

In my presentation at the WG meeting I used, as SIIT did:

"IPv4-mappED" (past tense, meaning the mapping already happened
   in order to get an IPv6 address) for addresses used to
   represent IPv4 hosts

"IPv4-translatABLE" (future tense, meaning the mapping
   has not yet happened, when you have an IPv6 address)
   for addresses assigned to IPv6 hosts

Of course the last term only applies to translation not
encapsulation, and Softwires folk wanted the doc to
cover both.  So I suppose "IPv4-mappable" could be
used for addresses assigned to IPv6 hosts.

(Just pointing this out because you suggested
IPv4-mappable be used for addresses used to
represent IPv4 hosts, which is backwards.)

-Dave

---

From: Rémi Després <[email-masked]>
Date: Wed, 2 Sep 2009 12:17:01 +0200

Dave,

I should have explained more the rationale for "IPv4-mappable" (I did  
know and understood the words you used in your presentation).

In a given translator, the IPv6 address used to represent an IPv4  
host and the IPv4 address of this can be mapped both ways.
This IPv6 address can therefore be viewed as mappable to the IPv4  
address as well mappable from it.
When it traverses the translator, the destination becomes the result  
of a mapping from the mappable address to the mapped address.

As you rightly decided, "IPv4-mapped" couldn't be a generic term for  
addresses "used to represent IPv4 hosts" because it is linked to a  
specific format.

Now, IPv4-mappable has two properties:
- it isn't reserved for a specific format
- because of the reversibility, its semantic is not less adequate  
than that of IPv4-mapped.

Actually, IPv6 addresses that exist before any traversal of an IPv6/ 
IPv4 translator, like addresses used to represent IPv4 hosts, would  
be more intuitively called mappable than a mapped. (A minor point I  
would agree, but still a point IMHO)

Does this make sense, or do I still miss something?.

Regards,
RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Sep 2009 12:52:51 +0200

> understanding better reflect points that were made.

I disagree with this. Leave the u/l and group bits alone.

---

From: Xing Li <[email-masked]>
Date: Fri, 11 Sep 2009 07:01:22 +0800

> I disagree with this. Leave the u/l and group bits alone.

we have methods to leave the u/l and group bits alone for the stateless 
translator even the prefix length is longer than 64 bits.

xing

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>