Mark,
Clearly, this does not comply with the addressing architecture. But I think
that the best we can do is to limit the damage.
Ron
From: Mark Smith <[email protected]>
Sent: Monday, October 14, 2019 4:08 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email protected]>
Cc: Ron Bonica <[email protected]>; Robert Raszuk <[email protected]>; SPRING
WG List <[email protected]>
Subject: Re: [spring] IPv6 Addresses and SIDs
On Mon, 14 Oct 2019, 16:45 Wang, Weibin (NSB - CN/Shanghai),
<[email protected]<mailto:[email protected]>> wrote:
Hi Ron:
Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6 domain,
then trouble situation you described does NOT occur, because the IPv6 address
covered within SRv6 SID prefix does not be involved ICMPv6 ND protocol, because
they are not configured under IP interfaces connected to “Link”.
That does not comply with the IPv6 Addressing Architecture RFC.
(I think this is the 4th time SPRING have or are ignoring IPv6 specifications.)
I also think that the authors of NET-PGM draft have indicated that SRv6 SID has
a separate IPv6 block in their Draft, but they don’t yet clearly stated which
IPv6 block will be used for it.
--------------------------------------
Cheers !
WANG Weibin
Juniper Business Use Only
From: spring <[email protected]<mailto:[email protected]>> On
Behalf Of Ron Bonica
Sent: 2019年10月14日 9:23
To: Robert Raszuk <[email protected]<mailto:[email protected]>>
Cc: SPRING WG List <[email protected]<mailto:[email protected]>>
Subject: Re: [spring] IPv6 Addresses and SIDs
Robert,
Yeah, there were a few typos in my original message. What I meant to say was:
* If a /64 contains a SID, it MUST NOT contain any addresses that represent
interfaces.
* If a /64 contains an address that represents an interface, it MUST NOT
contain SIDs.
If we don’t do this, we have to specify how nodes behave when they receive
ICMPv6 NS messages in which the target is:
* A locally instantiated SID
* A SID learned from the IGP
Ron
From: Robert Raszuk <[email protected]<mailto:[email protected]>>
Sent: Sunday, October 13, 2019 6:57 PM
To: Ron Bonica <[email protected]<mailto:[email protected]>>
Cc: SPRING WG List <[email protected]<mailto:[email protected]>>
Subject: Re: IPv6 Addresses and SIDs
Hi Ron,
/64 prefix is a pile of addresses ... 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 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]<mailto:[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]<mailto:[email protected]>>
Sent: Sunday, October 13, 2019 5:24 PM
To: Ron Bonica <[email protected]<mailto:[email protected]>>
Cc: SPRING WG List <[email protected]<mailto:[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]<mailto:[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
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!SEkBOAmRsYlBjRKWx1gZ4eegKkzZOKQgTtZuXxMv5TgCiZMT9xl0OH0Q8pbdZee9$>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
