+spring Hi Joel, you’ve described sections titled “Intra SR Domain Packet”, “Transit Packet Through SR Domain”, and "SR Source Nodes Not Directly Connected”.
I’ve parsed them inline to the sections of the draft defining them and given more context where needed. On Oct 22, 2018, at 8:49 PM, Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> wrote: Rephrasing using the example from 5.2. Assuming that 8 and 9 are SR Hosts (not just hosts within the domain, they are capable of and expect to deal with SRHs, and therefore have local SIDs, ...) For traffic from 8 to 9 that needs an SRH, the SRH goes in the IPv6 header sent my 8 to 9. When 9 processes the packet, it seems that it is the last SID, figures out that there is no encapsulation, and send the TCP / UDP / QUIC information to its internal protocols stacks. Yes, this is Section 5.3.1 “Intra SR Domain Packet”. For traffic from 1 to 9, where 3 adds an SRH, that SRH still presumably ends at 9. 9 Receives the IP packet. Sees that it is addressed to itself. Sees that the SRH is finished. And then notices that the next-header is IPv6. Unwraps the header, checks that the inner destination address is also itself, and passes the material carried by the inner header up to the appropriate stack. So node 1 sends a packet to node 9 (A1,A9) IF there is some steering into an SR Policy at node 3 to reach node 9, this is identical to section 5.3.2 “Transit packet through SR domain”, except for destination of A9 via node 9 instead of A2 via node 4. Thus, 9 needs to be able to check for both cases. We at least need to tell implementors that. Well, 9 needs a SID S9 and Address A9. That is shown in Section 5.1 SID and address representation. There is a further complication. 9 seems to need to have an address that is a valid SID, so it can be the last entry in the SRH from 8 to 9. As described in the draft, Section 5.1 a node k has an address Ak and SID Sk. So node 9 has a valid SID. For traffic from 8 to 9, A9 is used as the destination as shown in section 5.3.1, 5.4 and 5.5. However, if 1 were to send the packet to that SID for 9, router 3 would be required by the rules we discussed in the other thread to discard the packet as it is neither to prefix nor contains an HAMC. And somehow, 8 and 1 need to each pick the right address to use for 9. (split DNS maybe?) And 3 needs to be able to derive teh SID-formn address for 9 from the non-SID form of the address so that it (3) can build a proper SRH to get the packet to 9. This is incorrect. See Section 6.2.1 “SR Source Nodes Not Directly Connected” I will expand on the example from that section. Node 20 sends a packet to A9 with SR Policy <H7> and an HMAC provided to node 20 by some yet to be defined method. Resulting in packet sent from node 20 P: (A20,H7)(A9;SL=1)(payload) Recall Hk is a SID at node k requiring HMAC verification, and it is covered by Prefix-H. Prefix-H is _not_ subject to ingress filtering at node 3. Therefore the packet P destined to H7 is not subject to ingress filtering at node 3. P is forwarded to node 7, where H7 is processed and the HMAC verified. If the HMAC can not be verified the packet is dropped, else it is forwarded to the next segment and destination, A9. Darren Yours, Joel On 10/22/18 8:04 PM, Darren Dukes (ddukes) wrote: inline. On Oct 22, 2018, at 7:21 PM, Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> wrote: .. 2) Now let us look at packets arriving at and actually destined for an SR Host in the SR Domain where that packet has an SRH. If the packet is coming from another SR Host, the SRH will be in the base header, and the host can simply check it for any violations, and continue. But, if the packet came from outside the domain, then it will have an encapsulating SRv6 header. So the host has to detect this case, check and then peal off the encapsulating header, and then process the received packet. Yes, it can do so. But nothing in teh document tells implementors they have to deal with both cases. Can you be more precise here. Perhaps use the example from section 5.2 or 6.2.1? .. -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
