This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] 96 more bits... time for some magic after all?
- Previous message (by thread): [ipv6-wg] Request for feedback on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security
- Next message (by thread): [ipv6-wg] 96 more bits... time for some magic after all?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Fri Oct 25 12:37:00 CEST 2013
All, [ gah... hit the wrong key and sent this unfinished ] We saw two presentations by network architects at the RIPE meeting that used bits in their IPv6 addressing plan to carry meaning beyond simple network topology and packet routing. For example, declaring a specific bit in the address to be 1 for voice traffic or 0 otherwise. There are motivations for doing this, which may or may not be valid in any particular case. There are ways to lessen the amount of addresses consumed by this (for example by assigning /56 instead of /48 to end users). But I think that the important thing is that we have historically not considered this sort of use with address allocation policy. In face, RFC 2050bis was *just* published as RFC 7020: http://datatracker.ietf.org/doc/rfc7020/ This includes the long-standing historical goals of conservation, aggregation, and accuracy. Using bits in IPv6 networks for other purposes is orthogonal to those goals. What should we do about it? Cheers, -- Shane
- Previous message (by thread): [ipv6-wg] Request for feedback on IETF I-D draft-v6ops-vyncke-balanced-ipv6-security
- Next message (by thread): [ipv6-wg] 96 more bits... time for some magic after all?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]