Perhaps a simpler way to express the IP-in-IP encapsulation proposal would be: "authenticate over the tunnel interface, then configure over the physical interface". IP-in-IP encapsulation to solve a fragmentation/reassembly issue: how's *that* for irony?!
But, let's put that proposal aside for now and look at a different approach. Let us define a new DHCP option called the "DHCP fragment option" which has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where "Flags" and "Fragment Offset" have exactly the same format and useage as for RFC791 IP fragmentation except that the fragmentation occurs at the DHCP level; not IP. We say that this option must occur as the first option in the options field of each DHCP packet, and that multiple DHCP packets with the same xid are sent when there are multiple fragments (the xid also serving as an identification for reassembly). Each fragment except the final fragment would have length=2. The final fragment would have length=4 and would include a 16-bit checksum immediately following the Fragment Offset field. The checksum would include a 16-bit Fletcher checksum calculation over the DHCP packet before fragmentation (details as to which fields are covered by the checksum to be specified later). Or, maybe we should use the sprite-mtu checksum (draft-templin-inetmtu) instead. Come to think of it, we probably don't even need the "Flags" field and can use all 16 bits for the fragment offset - but, I think you get the big picture of where I'm going with this... Thanks - Fred [EMAIL PROTECTED] > -----Original Message----- > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 31, 2007 4:44 AM > To: Templin, Fred L > Cc: Yoshihiro Ohba; Ralph Droms; Internet Area > Subject: Re: [Int-area] DCHP-based authentication for DSL? > > On Tue, Oct 30, 2007 at 03:40:06PM -0700, Templin, Fred L wrote: > > 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. > > In that case, how the DHCP client can know that authentication > messages needs to be used? > > > > > > - 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. > > I think that a collision must not happen. If not, it's not the right > approach, IMO. > > > > > > 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'. > > I don't think DHCP server is supposed to include in 'yiaddr' an > address that is not allocated by the server > > > > > > 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. > > I am not sure if I understand your comment. Isn't RFC3927 address > assigned to the physical interface? > > Yoshihiro Ohba > > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
