At the risk of further diversion on what may/may-not be a problem: > > It's just a proposal, and I haven't studied the problem > > (if there is one) in detail. But, I don't agree wrt the > > simplicity aspect. > > - An additional mechanism would be needed for DHCP client and DHCP > relay/server to know the IP-in-IP capability as well as > the tunnel endpoint address of the peer.
I was thinking that IP-in-IP would be used IFF messages that support authentication are used. So, the use of the authentication messages implies the use of IP-in-IP encaps. > - Use of IP-in-IP with IPv4 Link-Local address for DHCP would > introduce not only potential for collision in the server/relay's > reassembly cache, But, much less so than for the unspecified source address. and any collisions would be detected by udp checksums and dropped. Result is that client simply retries. > but a requirement for DHCP server/relay to maintain > mapping between hardware address and IPv4 L-L address of DHCP client, > because hardware address is no more sufficient to deliver DHCP message > to DHCP client. I'm not entirely sure this is true, and if it were I don't necessarily see a problem; the server could just echo the LL in 'yiaddr'. > These issues would affect the following requirement > in RFC 3927 on IPv4 L-L address: "A host MUST NOT alter its behavior > and use of other protocols such as DHCP because the host has assigned > an IPv4 Link-Local address to an interface." There are two interfaces in question: 1) the interface connected to the physical link over which the client is attempting to configure a global address, and 2) the virtual interface used for IP-in-IP encapsulation. The RFC3927 address would be assigned to interface #2; not interface #1. By my read of the RFC3927 text you quoted, the concern is specific to the case of both LL and global being assigned to the same interface; not different ones. > - DHCP over IP-in-IP does not address the issue on L2 devices > requiring reaassembly of fragmented IP datagarams to do DHCP snooping. This is outside of my expertise, but how is the situation any different for any protocol that is subject to IP fragmentation? Fred [EMAIL PROTECTED] > Yoshihiro Ohba > > > > > > > > > > Fred > > [EMAIL PROTECTED] > > > > > > > Yoshihiro Ohba > > > > > > On Tue, Oct 30, 2007 at 09:19:53AM -0700, Templin, Fred L wrote: > > > > If I understand the situation correctly (fragmentation > > > > needed with packets having 0.0.0.0 source address), a > > > > potential mitigation is through the use of IP-in-IP > > > > encapsulation and RFC3927 link local addresses. A > > > > DHCP/EAP client which does not yet have an address can > > > > then wrap its DHCP messages in an inner IP header with > > > > an RFC3927 source address and an outer IP header with > > > > a source address of 0.0.0.0. Both the inner and outer > > > > destination address would be that of the DHCP/EAP > > > > server. > > > > > > > > During the encapsulation, the client can fragment the > > > > inner DHCP message into inner IP fragments no larger > > > > than the path MTU minus 20 bytes, then encapsulate each > > > > inner fragment in an outer IP header with DF=1. > > > > > > > > In this sense, the RFC3927 address is still a link-local, > > > > because the tunnel between the client and the server is > > > > just an ordinary link from IP's perspective. There is a > > > > potential for collision in the server's reassembly cache > > > > with other clients choosing the same link-local address, > > > > however the inner ip-id can be used for further > > > > differentiation. In the event of collision in both the > > > > ip-src and ip-id planes, the UDP checksum is available > > > > to detect reassembly corruption and the sprite-mtu > > > > checksum (draft-templin-inetmtu-05) could also be used > > > > if an additional and complementary check is desired. > > > > > > > > Or, maybe I am misunderstanding the situation? > > > > > > > > Fred > > > > [EMAIL PROTECTED] > > > > > > > > > -----Original Message----- > > > > > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, October 29, 2007 4:43 AM > > > > > To: Ralph Droms > > > > > Cc: Internet Area > > > > > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > > > > > > > > > On Sun, Oct 28, 2007 at 04:22:27PM -0400, Ralph Droms wrote: > > > > > > The only reference to fragmentation in RFC 951 is: > > > > > > > > > > > > 3. Packet Format > > > > > > > > > > > > [...] For > > > > > > simplicity it is assumed that the BOOTP packet is never > > > > > fragmented. > > > > > > > > > > > > There are no references to fragmentation in RFC 213[12] > > > or RFC 3315. > > > > > > > > > > > > In my opinion, this reference is to simplicity in the IP > > > > > layer, not > > > > > > in the BOOTP layer. The IP layer handles any fragmentation > > > > > and the > > > > > > BOOTP/DHCP layers are unaware of that fragmentation. > > > > > Therefore, any > > > > > > addresses included in the DHCP messages are irrelevant to > > > > > BOOTP/DHCP > > > > > > message reassembly. > > > > > > > > > > I don't think IP layer can correctly reassemble IP > > > datagrams with the > > > > > unspecified source address (0.0.0.0) which breaks > uniqueness of > > > > > fragments among multiple *different* source nodes. > > > > > > > > > > > > > > > > > On the other hand, as I wrote in a previous message, all > > > > > bets are off > > > > > > regarding L2 (or other) devices that snoop the DHCP > > > > > messages without > > > > > > performing IP reassembly. > > > > > > > > > > Sure, this is another issue. > > > > > > > > > > > > > > > > > And, as a practical matter, I suspect all extant DHCP > > > clients and > > > > > > servers have a DHCP message MTU less than 1500 octets. > > > > > > > > > > For the above reasons, DHCP message should not be > IP-fragmented. > > > > > However, DHCP message MTU being not more than link-layer > > > MTU can be a > > > > > non-workable requirement when carrying EAP, considering > > > the fact that > > > > > EAP can consume up to 1020 octets and additionally other > > > options need > > > > > to be carried in a DHCP message. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > - Ralph > > > > > > > > > > > > > > > > > > On Oct 25, 2007, at Oct 25, 2007,8:28 PM, Yoshihiro > Ohba wrote: > > > > > > > > > > > > >Isn't DHCP designed based on the same assumption as BOOTP > > > > > in terms of > > > > > > >IP fragmentation? BOOTP assumes that BOOTP > messages are never > > > > > > >fragmented according RFC 951. > > > > > > > > > > > > > >An issue with fragmenting DHCP message I can think of is > > > > > that a DHCP > > > > > > >relay agent or server may not be able to correctly > reassemble > > > > > > >fragmented messages when simultaneously received from > > > multiple DHCP > > > > > > >clients if the source address of those messages is > unspecified > > > > > > >(0.0.0.0). How does DHCP address this issue? > > > > > > > > > > > > > >Note: DHCPv6 does not have this issue because a specified > > > > > address is > > > > > > >always used. > > > > > > > > > > > > > >Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > >On Wed, Oct 24, 2007 at 05:03:01PM -0400, Ralph > Droms wrote: > > > > > > >>Sorry, I made a goof. Relay agents can forward > > > fragmented DHCP > > > > > > >>messages. There is, if I recall correctly, a > > > > > recommendation against > > > > > > >>fragmentation (perhaps RFC 2131); however, the stack > > > on the node > > > > > > >>where the relay agent is instantiated will > > > re-assemble the DHCP > > > > > > >>message before delivering it to the relay agent, and then > > > > > re-fragment > > > > > > >>the new DHCP message resent by the relay agent. > > > > > > >> > > > > > > >>- Ralph > > > > > > >> > > > > > > >>On Oct 24, 2007, at Oct 24, 2007,4:54 PM, Ralph > Droms wrote: > > > > > > >> > > > > > > >>>Section 6.3 of draft-pruss-dhcp-auth-dsl-01 > > > addresses how to fit > > > > > > >>>the EAP info into DHCP options, using RFC 3396. > > > > > > >>> > > > > > > >>>However, there is also a recommendation, when using > > > EAP, that the > > > > > > >>>server set the "Maximum DHCP Message Size" option to > > > > > 1604. Sending > > > > > > >>>a DHCP message of this size may require > > > fragmentation, but DHCP > > > > > > >>>relay agents cannot forward fragmented DHCP messages. > > > > > > >>> > > > > > > >>>- Ralph > > > > > > >>> > > > > > > >>>On Oct 24, 2007, at Oct 24, 2007,4:36 PM, Richard > > > Pruss wrote: > > > > > > >>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>Stig Venaas wrote, around 24/10/07 7:23 PM: > > > > > > >>>>>It's not as simple as just putting credentials > > > into option 82 > > > > > > >>>>>though. > > > > > > >>>>>For one thing there are strict limits on the > size of DHCP > > > > > > >>>>>messages that > > > > > > >>>>>will limit what EAP or other mechanisms you can use. > > > > > When the EAP > > > > > > >>>>>MTU is too small for the EAP message, you need > multiple > > > > > > >>>>>requests and > > > > > > >>>>>responses to transport the message. This is not > > > > > possible without > > > > > > >>>>>major DHCP changes. Hence you are not free to > use what EAP > > > > > > >>>>>mechanisms > > > > > > >>>>>or credentials you like without major changes to DHCP. > > > > > While with > > > > > > >>>>>say > > > > > > >>>>>PANA you could do that. > > > > > > >>>>> > > > > > > >>>>Stig section 6.3 of the currently posted -01 draft > > > addresses the > > > > > > >>>>size issue of EAP in some detail, it is not > clear if you are > > > > > > >>>>saying the proposed mechanism would not work. > > > > > > >>>> > > > > > > >>>>Regardless of the mechanism if one thinks of > this from the > > > > > > >>>>implementation it should be no big deal as for EAP and > > > > > RADIUS one > > > > > > >>>>has to chop EAP into small enough chunks to get through > > > > > > >>>>limitations in RADIUS (<253 bytes). While DHCP > has similar > > > > > > >>>>problems (<255 bytes), and one could can expect > that most > > > > > > >>>>networking companies would have implemented the > lower common > > > > > > >>>>denominator of RADIUS here. > > > > > > >>>> > > > > > > >>>>Regards, > > > > > > >>>>Ric > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>_______________________________________________ > > > > > > >>>>Int-area mailing list > > > > > > >>>>[email protected] > > > > > > >>>>https://www1.ietf.org/mailman/listinfo/int-area > > > > > > >>> > > > > > > >>> > > > > > > >>>_______________________________________________ > > > > > > >>>Int-area mailing list > > > > > > >>>[email protected] > > > > > > >>>https://www1.ietf.org/mailman/listinfo/int-area > > > > > > >> > > > > > > >> > > > > > > >>_______________________________________________ > > > > > > >>Int-area mailing list > > > > > > >>[email protected] > > > > > > >>https://www1.ietf.org/mailman/listinfo/int-area > > > > > > >> > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Int-area mailing list > > > > > [email protected] > > > > > https://www1.ietf.org/mailman/listinfo/int-area > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
