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

RE: IPv6

 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson
> Sent: 06 October 2009 23:39
> To: radiusext@ops.ietf.org
> Subject: Re: IPv6
> 
> 
> On Oct 6, 2009, at 5:14 PM, Wojciech Dec (wdec) wrote:
> 
> > That same RFC 2865, in section 5, states:
> >
> >      string    1-253 octets containing binary data (values 0 through
> >                255 decimal, inclusive).  Strings of length zero (0)
> >                MUST NOT be sent; omit the entire attribute instead.
> >
> > With that, Ipv6 Prefix, Route options, 
> Auth-IPv6-Prefix-User-ID, etc 
> > would be pretty much covered by using the string term.
> 
> With all due respect, the String data type is just a string of  
> undistinguished octets.   While you may conceptually overlay 
> it with a  
> structure, i.e define sub-fields, that action creates a new 
> data type.  In other words, the String type is just a string. 
>  You may lament the fact that RADIUS, as defined in RFCs up 
> through 2865, has no method to formally define structured 
> data, but the fact is that it has none.

Sure, that's fair. The point I was making is that with the string
definition above, passing an IPv6 prefix (or anything else up to 255
bytes really) did not require any new data-type and in terms of say the
IPv6-prefix. Furthermore rfc2868 provides plenty of precedent for
structured attributes with "String", if one wants, eg Tunnel-Password.

-Woj.


> 
> 
> --
> 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/>
> 

--
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/>