|
RFC 2865, Section 5.9 defines Framed-IP-Netmask: This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint. In contrast, Section 5.22 defines Framed-Route as the mechanism for configuring routing information: This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. Based on this, it would appear that Framed-IP-Netmask is intended for configuration of hosts, not routers, and that Framed-Route is to be used to configure routes. Defining two mechanisms for configuration of routes seems like it could create potential interoperability problems. Since RFC 2865 is a Draft Standard, the existing mechanisms are known to be interoperable. > Pasi made a comment regarding the DISCUSS about RFC2865 that says: > > * RFC 2865, by defining new interpretations of the Framed-IP-Address > > and Framed-IP-Netmask attributes. > > > > Would adding this text clarify (and remove your concerns with) Section > > 8.2.2? > > > > @@ -1551,7 +1551,14 @@ > > attributes [RFC2865] may be used by the Softwire Concentrator to > > delegate an IPv4 prefix to the Softwire Initiator. > > > > + As this practice had been used, the inclusion of the Framed-IP- > > + Netmask attribute tells the Softwire Concentrator to delegate an > IPv4 > > + prefix to the Softwire Initiator (e.g., in the IPv4 over IPv6 > > + scenarios where the Softwire Initiator is a router, see Section > 3.2.2 > > + and Section 3.2.4), as the SC should forward packets destined to > any > > + IPv4 address in the prefix to the SI. > > > > > > Please let me know if this helps with the Framed-IP-Netmask issue. > > > > Thanks, > > > > Thanks, > > -- Carlos. |