> My architectural concern is that the proposal (DHCP + EAP + > DHCP-fragmentation) is towards adding more and more complexity to IP > host that is not in a fully functional state. An IP host is not fully > functional until they have an IP address. The fragmentation issue > comes out of this fact. I think this proposal is just a wrong > approach to address DSL authentication issue.
This sounds like more of a philisophical concern than a technical one. You posed a technical issue, and I proposed a technical solution. If there are technical shortcomings, they should be expressed and considered as well. Thanks - Fred [EMAIL PROTECTED] > Yoshihiro Ohba > > > > On Thu, Nov 01, 2007 at 09:03:43AM -0700, Templin, Fred L wrote: > > > Defining a DHCP option that spans multiple DHCP messages for > > > DHCP-layer fragmentation seems to be another significant change to > > > DHCP. This is not just a matter of how to handle the > proposed DHCP > > > option but it can affect the basic DHCP message processing rule in > > > which only one DHCP message is generated in response to one DHCP > > > message. > > > > I'm not sure I understand the concern. The client can > > tell the server that it supports DHCP fragmentation by > > including a DHCP fragment option in its initial DISCOVER > > even though the message is sent as a single fragment. > > The server then knows that the client can accept and > > reassemble fragmented DHCP messages, and can include a > > DHCP fragment option in the OFFER/EAP response so that > > the client can know that the server supports it too. > > > > Fred > > [EMAIL PROTECTED] > > > > > Yoshihiro Ohba > > > > > > On Wed, Oct 31, 2007 at 08:16:54AM -0700, Templin, Fred L wrote: > > > > 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
