RE: IPv6

["Glen Zorn" <glenzorn@comcast.net>]

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > Alan DeKok [mailto://aland@deployingradius.com] writes:
> >>   RADIUS attributes are typed.
> >
> > In your mind, perhaps; in the real world (where RFC 2865 exists), one
> may
> > read page after page without ever seeing an attribute "typed".
> 
>   Ah... the RFC 2486 definition that the NAS-IP-Address attribute is an
> "ipv4 address" is just there for joviality.  

Must be a typo -- RFC 2486 nowhere mentions the NAS-IP-Address attribute &
doesn't contain the (case-folded) string "IPv4".  What are you actually
talking about?

> It can really be anything
> you want.

This is how RFC 2865 defines the attribute:

5.4.  NAS-IP-Address

   Description

      This Attribute indicates the identifying IP Address of the NAS
      which is requesting authentication of the user, and SHOULD be
      unique to the NAS within the scope of the RADIUS server. NAS-IP-
      Address is only used in Access-Request packets.  Either NAS-IP-
      Address or NAS-Identifier MUST be present in an Access-Request
      packet.

      Note that NAS-IP-Address MUST NOT be used to select the shared
      secret used to authenticate the request.  The source IP address of
      the Access-Request packet MUST be used to select the shared
      secret.

   A summary of the NAS-IP-Address Attribute format is shown below.  The
   fields are transmitted from left to right.

    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      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      4 for NAS-IP-Address.

   Length

      6

   Address

      The Address field is four octets.

That's all, "four octets".  Note that the "Address" data type is defined
previously in the document but it's not used here.  Could be a "string" of
length 4, could be an "Integer", could be an "Address".  This may seem
frivolous, but it's related to David's comments in another message: it
actually doesn't matter what the data type is because everybody _knows_ that
it's an IPv4 address -- we are 'conceptually overlaying' the 4 octet field
with a contiguous sub-field interpreted as an IPv4 address.  The same thing
happens all over the place in RFC 2865 and if David is correct then  the
"data" fields in probably half the attributes defined therein are unique
data types.

> 
>   Or, as the design guidelines document says:
> 
>    Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
>    not define a formal data definition language.  A handful of basic
>    data types are provided, and a data type is associated with an
>    attribute when the attribute is defined.

But that's not true, either - a single counterexample would suffice & I've
already given half a dozen.

> 
> >> The list of types is small.  Each type
> >> is statically defined in an RFC.
> >
> > In what RFC is the "8-bit Tag + 24-bit Integer" "data type" defined?
> That's
> > easy, none.  The fact that some implementations _treat_ it as a "data
> type"
> > doesn't make it so, since there are other ways to implement a tag.
> 
>   Strange.  I was talking about the protocol, and the definition of
> attributes.  Having done some minor programming from time to time, 

I just want to note that I deserve MAJOR style points for letting that one
pass ;-).

> I am
> aware of the difference between wire encoding and data structures
> internal to an implementation.
> 
>   Would you be happier if I said "there are a limited number of data
> formats that are encoded/decoded on the wire" ?  Maybe that would make
> it clearer that I am talking about the protocol.

I'd be happier if you didn't use the same term to name two entirely
different things.

> 
>   New formats require new encoders/decoders.  Is that controversial?
> 
>   Re-using existing formats is usually good.  Is that controversial?

Both those statements seem implementation-specific to me.


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