While I'd like to see some consideration of prefix-based control, a security considerations discussion of access limitation via an IPv6 firewall is ok (but it *needs* text in the security considerations section), and Brian's proposed "SHOULD NOT" for the use of dynamic IPv4 addresses for 6to4 sites with reverse DNS delegation is fine - that should be sufficient warning for the surprise that a DHCP reassignment may cause inheritance of someone else's remote DNS delegation (if this happens, it was a consequence of ignoring the "SHOULD NOT").
Thanks, --David > On 2007-07-17 20:06, [EMAIL PROTECTED] wrote: > ... > > The draft is in generally good shape, but I think the first > > two potential issues noted in Section 4 Delegation Administration > > need further attention: > > > > o Clients inside a 6to4 site could alter the delegation details > > without the knowledge of the site administrator. It is noted that > > this is intended for small-scale sites. Where there are potential > > issues of unauthorized access to this delegation function the > > local site administrator could take appropriate access control > > measures. > > > > Independent of intent, this will get used for larger scale sites. > > Some form of prefix control exercisable by the site administrator > > would be a good idea. This may not be possible in all cases as > > details of provider address allocation aren't always available > > beyond the address block allocated by the registry, but the topic > > needs some more thought. Failing that, this is a v6 firewall > > configuration issue, and the need for a firewall to support this > > for administratively-controlled multi-address sites should be > > called out in the Security Considerations section. > > It doesn't seem hard - it means that access to https://6to4.nro.net > has to be controlled, and there are many firewalls intrusive > enough to do that. > > > > > o IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses > > dynamically-assigned external IPv4 interface addresses, could > > inherit nonsense reverse entries created by previous users of the > > dynamically assigned address. In this case the client site could > > request delegation of the reverse zone as required. > > > > This is an invitation to serious problems. There ought to be a > > way in the service to add a delegation expiration time when a > > delegation is requested (e.g., a slightly smart piece of client > > software could then put in the DHCP lease expiration time and > > update the delegation when renewing the DHCP lease). Inheriting > > someone else's reverse DNS delegation because DHCP re-allocated > > the IP address is not what I would consider expected behavior. > > > > No, but the combination of 6to4 in site mode with a single > dynamically assigned IPv4 address for a whole site seems a little > outside the parameters 6to4 was designed for. Remember that a 6to4 > site also has to establish an ongoing relationship with a 6to4 relay > router. I don't think a model where all that has to be re-done > after a power cut or an ISP glitch is very plausible. Rather than > adding a lifetime mechanism, why need make this a SHOULD NOT? > (i.e. If reverse delegation is needed the site SHOULD NOT use > a non-fixed IPv4ADDR for 6to4.) > > Brian > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
