Sheng, > Back in Atlanta, in DHC WG meeting, you said you would review the document. > Could you give the comments?
I knew that would come back and haunt me. ;) comments below. also included dhc and 6man >> Draft: Prefix Assignment in DHCPv6 >> Presenter: Sheng Jiang >> URL: http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-04 >> Slot: 5 min > >> ** Ole will review the document and maybe bring it up on 6man > > Many thanks and best regards, in arbitrary order: - draft-ietf-mif-dhcpv6-route-option also supports prefix discovery using DHCP - a host wanting a particular address, why can it not use the "hint" option in a vanilla IA_NA? - a prefix on a link must always be coordinated with the onlink router, so I don't understand the argument of why the "L-flag" isn't needed - we shouldn't create new DHCPv6 options with T1/T2 timers. those should be put in a separate option - what do you do if the prefix length is different from /64? in general I think the use case presented is already supported by DHCPv6 address assignment; the client puts the addresses it desire as hints in the IA_NA option in DHCPv6 requests. I think the argument given in the draft for operators wanting a DHCPv6-managed network without ND is flawed. ND is required for router discovery, neighbour discovery etc anyway. and a router on the link must be configured with the onlink prefix regardless. while we can clearly make this work, I don't think it is justified to create a duplicate mechanism for prefix discovery. section 3.2 RFC1958. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
