On Mon, 14 Oct 2019 at 09:57, Robert Raszuk <[email protected]> wrote: > > Hi Ron, > > /64 prefix is a pile of addresses ...
It's more than that, there is an addressing model to follow. From RFC 4291, "2.1. Addressing Model IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node." > if someone would be to follow your suggestion I could not allocate some > blocks of that prefix on R1, then some other blocks on R2 then yet more on my > servers. > You would have to divide your /64 of into smaller subnets to do that. > You said: > > “With a /64, if one /128 represents an IPv6 interface, as described in RFC > 4291, all /128 MUST either: > > > > Represent an IPv6 interface, as described in RFC 4291, or > Be unassigned” > > > Maybe you meant to say something else: > > “When a /64 is used as SRv6 locator prefix, if one /128 represents an IPv6 > interface, as described in RFC 4291, all /128 MUST either: > > > > Represent an IPv6 interface, as described in RFC 4291, or > Be unassigned” > > But then you sent this to SPRINT indicating that 6MAN should be the audience > :). > > Best, > R. > > > On Mon, Oct 14, 2019 at 12:45 AM Ron Bonica <[email protected]> wrote: >> >> Robert, >> >> >> >> I’m having a hard time understanding exactly how I have violated the longest >> match principle. Could you provide: >> >> >> >> A pointer to a statement of the longest match principle >> A few words regarding how I have violated it >> >> >> >> Ron >> >> >> >> >> >> From: Robert Raszuk <[email protected]> >> Sent: Sunday, October 13, 2019 5:24 PM >> To: Ron Bonica <[email protected]> >> Cc: SPRING WG List <[email protected]> >> Subject: IPv6 Addresses and SIDs >> >> >> >> Hi Ron, >> >> >> >> I disagree. >> >> >> >> Your suggestion violates longest prefix match principle in routing. >> >> >> >> It is huge waist of address space and is not specific to IPv6 at all. >> >> >> >> Let me describe the deployment case where your suggestion would cause it to >> break: >> >> >> >> I have /64 prefix where a few /128s from that space I allocate to local >> interfaces making it a local v6 destinations on those nodes. >> >> >> >> However in the spirit of CIDR I still want to to use some blocks of that >> space - say /126 or /124 as blocks which I only use to trigger local NAT as >> per rfc6296. And NAT does not require local address to be a destination >> address so it would be a big disservice to kill such deployment option. >> >> >> >> Many thx, >> R. >> >> >> >> >> >> On Sun, Oct 13, 2019 at 10:59 PM Ron Bonica >> <[email protected]> wrote: >> >> Folks, >> >> >> >> I think that we need a global rule that says: >> >> >> >> “With a /64, if one /128 represents an IPv6 interface, as described in RFC >> 4291, all /128 MUST either: >> >> >> >> Represent an IPv6 interface, as described in RFC 4291, or >> Be unassigned” >> >> >> >> The 6man WG will need to make such a statement since it owns RFC 4291. >> >> >> >> Ron >> >> >> >> Juniper Business Use Only > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
