[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 6rd attribute compromise?

To: Alan DeKok <aland@deployingradius.com>
Subject: Re: 6rd attribute compromise?
From: Jiangsheng <jiangsheng@huawei.com>
Date: Tue, 12 Apr 2011 03:25:30 +0000
Accept-language: en-GB, zh-CN, en-US
Cc: Peter Deacon <peterd@iea-software.com>, radiusext <radiusext@ops.ietf.org>

Hi, Alan and Peter,

Sorry for the late reply.

The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969.

However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS.

If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte.

The second choice could be we limit 6rdBRIPv4Address to be only 1 instance. Then we have a fixed length attribute. But this need to enable grouping multiple attributes module, which seems RADIUS protocol does not support currently.

We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC,
containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute?

Best regards,

Sheng & Dayong

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Follow-Ups:
- Re: 6rd attribute compromise?
  - From: Peter Deacon <peterd@iea-software.com>
- Re: 6rd attribute compromise?
  - From: Alan DeKok <aland@deployingradius.com>

Prev by Date: Re: Consensus poll for IANA #409959 NAS-Port-Type value request
Next by Date: Re: 6rd attribute compromise?
Previous by thread: Route-IPv6-Information Attribute
Next by thread: Re: 6rd attribute compromise?
Index(es):
- Date
- Thread