Subject: (ION) IPv6 over ATM draft

From: Albert Manfredi <[email-masked]>
Date: Mon, 27 Jul 1998 11:05:09 -0400

I have a couple of comments on darft-ietf-ion-ipv6-atm-02.txt:

First the simple one.

1. Unless this is some devilishly clever scheme, I think there's a
typo in Section 5.4. The half-byte order used to form an IPv6 token
out of an E.164 number shown should be:

    .... [D11D10][D9D8][D7D6] ....

rather than D9 being repeated twice as shown.

Now less straightforward comments.

2. In Section 4.1.7, the ATM address is shown to vary in length,
depending whether it is "native E.164" or AESA. But in the UNI 4.0
Annex 1 paragraph 9, it says to use the AFI and the next 8 bytes for
a native E.164 number, and then set the rest of the AESA bytes to 0,
so you're always sending 20 bytes. Would it not be possible to set
the ATM number to always be the same length here as well, just to
make things simpler?

3. In Section 5.1, it requires the token built from ESI + SEL to
always be identified as "not globally unique." Why is this? Might
the ESI not be an actual MAC value, assigned by the IEEE (and
therefore globally unique)?

4. Finally, back to Section 5.4, is it not simpler to generate an
IPv6 token, when native E.164 is used in the ATM net, by simply
encoding the E.164 number in binary? This requires only 6 bytes and
is going to have a higher probability of being unique than the
scheme shown, no?

Thanks.

Bert
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: "Markus Jork" <[email-masked]>
Date: Tue, 28 Jul 1998 09:56:22 +0200

Bert,

> I have a couple of comments on darft-ietf-ion-ipv6-atm-02.txt:

thanks for the feedback.

> rather than D9 being repeated twice as shown.

Yes, that's a typo.

> the ATM number to always be the same length here as well, just to

I'm not sure, I will let others answer this one.

> therefore globally unique)?

The ESI might in fact be a globally unique 48 bit MAC value. But
after combining it with the SEL byte you don't get a globally
unique EUI-64 value.

An IPv6 interface token is globally unique when (after inverting the
universal/local bit) it's globally unique in the EUI-64 space.

> is going to have a higher probability of being unique than the

But it also wouldn't create a globally unique EUI-64 value.

Markus

---

From: "Peter A. Schulter" <[email-masked]>
Date: Wed, 29 Jul 1998 13:37:00 -0400

> the ATM number to always be the same length here as well, just to

The reasons we decided to allow native E.164 addresses
were that this wouldn't require any conversion between AESA and
E.164 address on interfaces connected directly to a public UNI,
and well, all the other IP over ATM specs allow for native E.164
addresses.  I think that always using AESA would require all parties 
to know which type of ATM network they were connected to, and when 
to convert between E.164 and AESA.  That would add extra complexity. 
It's just easier to use the "native" address that is assigned to a node.

Thanks again for the comments,

 --- pete