Subject: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format

From: [email-masked]
Date: Tue, 27 Apr 2004 08:27:09 +0300

New submission from Dan Forsberg <[email-masked]>:

From Yoshihiro Ohba:
--------------------
The current Device-Id and EP-Device-Id AVP payload format is as
follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |           Data...                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the Type field can contain:

            RESERVED                          0
            IPV4_ADDRESS                      1
            IPV6_ADDRESS                      2
            L2_ADDRESS                        3

I think it might be better to use the Diameter Address type format for
Device-Id and EP-Device-Id AVPs instead of the current format.

The Diameter Address type is defined in RFC3588 as:

   Address
      The Address format is derived from the OctetString AVP Base
      Format.  It is a discriminated union, representing, for example a
      32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
      significant octet first.  The first two octets of the Address
      AVP represents the AddressType, which contains an Address Family
      defined in [IANAADFAM].  The AddressType is used to discriminate
      the content and format of the remaining octets.
                                                                                
Justification: It defines not only IPv4 and IPv6 address families but
also many L2 address families.  I think using L2_ADDRESS in the
currnet definition is too generic and might have ambiguity in an
environment where multiple L2 types can co-exist in a single IP
subnet.  On the other hand, since the address family also covers
higher-layer address types such as domain name, PANA must use only L2
or L3 address families.

----------
category: Technical
document: draft-ietf-pana-pana-xx.txt
messages: 263
nosy: dforsber
priority: Must Fix
status: Text Proposed
title: Device-Id and EP-Device-Id format
__________________________________________________
PANA Issues <[email-masked]>
<http://danforsberg.info:8080/pana-issues/issue83>
__________________________________________________
ڝ���X��X����j'�~����i����
bz���j)fj��b��?���

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 17:24:23 -0700

I think this is a good idea from code and protocol re-use perspective.
But I'm not sure if we can capture enough details this way.

"The AddressType is used to discriminate the content and format of the
remaining octets." does not say much about the exact format of the
address, or where to find it. Is this not a problem?

Also, I don't think there is a problem with the current design. The PANA
context is bound to an interface, both on the PAA and PaC. That
interface can support one L2-type, and hence inherently this type should
be used in parsing the L2_ADDRESS value.

Alper

>       |     Type      |           Data...
|
> =jz ~

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 17:24:23 -0700

Alper

|

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Apr 2004 18:38:31 -0700

> address, or where to find it. Is this not a problem?

I agree, we might need to add some text on the format of the remaining
octets.

> be used in parsing the L2_ADDRESS value.

What about EP-Device-Id?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 27 Apr 2004 18:38:31 -0700

What about EP-Device-Id?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 23:26:41 -0700

> I agree, we might need to add some text on the format of the remaining

And we don't want to that for each possible link type. We should
off-load this task to some other spec(s), like what we are doing now:

   The content and format of data (including byte and bit
   ordering) for L2_ADDRESS is expected to be specified in specific
   documents that describe how IP operates over different link-layers.
   For instance, [RFC2464].

> > be used in parsing the L2_ADDRESS value.

EP, PaC, and PAA are on the same subnet. I think we can assume that they
are using the same or at least somewhat compatible link-layer
technologies (e.g., IEEE 802.3 and 802.11b).

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Apr 2004 23:26:41 -0700

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 16:34:27 -0700

OK, here is a proposed text:

"9.4.2 Device-Id AVP
      
   The Device-Id AVP (Code 1025) is of Address type [RFC3588].  IPv4
   and IPv6 addresses are encoded as specified in [RFC3588].
   The content and format of data (including byte and bit
   ordering) for link-layer addresses is expected to be specified in
   specific documents that describe how IP operates over different
   link-layers.  For instance, [RFC2464].  Address families other than
   that are defined for link-layer or IP addresses MUST NOT be used
   for this AVP."

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Apr 2004 16:34:27 -0700

"9.4.2 Device-Id AVP

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 18:03:27 -0700

That looks good.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Wednesday, April 28, 2004 4:34 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] NEW: [issue83] Device-Id and EP-Device-Id format
> 
> > > > "The AddressType is used to discriminate the content and format
of
> > the
> > > > Also, I don't think there is a problem with the current design.
The
> > PANA
> > > > interface can support one L2-type, and hence inherently this
type
> > should

---

From: Alper Yegin <[email-masked]>
Date: Wed, 28 Apr 2004 18:03:27 -0700

That looks good.

Alper

of
The
type