I am sorry, but I don't think just cut-and-paste emails can convince people for something that is against the basic philosophy or archicture that, I believe, has been followed for a long time.
Yoshihiro Ohba On Thu, Nov 01, 2007 at 10:46:57AM -0700, Templin, Fred L wrote: > > I am sorry, but how can I put detailed technical comments without > > seeing a complete proposal? > > Sounds like a challenge to write up a draft. I can't > make any commitments as of this moment, but I don't > see a draft as saying much more/different than what > has been said already; maybe just cut-and-paste emails? > > Fred > [EMAIL PROTECTED] > > > > Yoshihiro Ohba > > > > > > On Thu, Nov 01, 2007 at 10:24:48AM -0700, Templin, Fred L wrote: > > > > 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
