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
