Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 3 Mar 2015 16:47:34 +0800

I am aware your reply just now, and was back to work yesterday from Chinese Lunar New Year holiday.

Ole - no, it is e.g. the /56 delegated to the end-user.

I got it.

Leaf > #4. In sec.6,
> “  The PSID field is left-padded to create a
>    16 bit field.  For an IPv4 prefix or a complete IPv4 address, the
>    PSID field is zero.”
> Q. Does the about ‘zero’ means the value of the PSID=0x 00, or the length of the PSID is zero? I guess it means the former, right?
Ole - correct.

I prefer we could replace the above 'zero' to be 'all 0s'.

Leaf > I think BR does not need to use the above IID. I prefer to replace the word ‘MAP node’ to be ‘MAP CE’. Right?
Ole - correct, but that leads us back to the discussion if the BR should be part of the MAP domain or not. that is should it be possible to reach an address of the BR using IPv4. that's why it says MAP node instead of MAP CE.

Sec.6 is named as "The IPv6 Interface Identifier". BR is not necessary to be reachable through IPv4, thought 'MAP node' sounds not wrong. 

Leaf > #7. In sec. 11
> “     They cannot
>       exist with MAP because each BRs checks that the IPv6 source
>       address of a received IPv6 packet is a CE address based on
>       Forwarding Mapping Rule. ”
> I think BRs check that the IPv6 source address of a received IPv6 packet is a CE address based on Basic Mapping Rule, and check that the IPv6 destination address of a received IPv6 packet is a CE address based on Forwarding Mapping Rule, right?
Ole -no, the destination IPv6 address is the BR address, and there is no point checking that.

Right, but my point was 'each BR (note that we don't need 's' here.) checks that whether the IPv6 source address of a received IPv6 packet is a CE address based on Basic Mapping Rule, not Forwarding Mapping Rule.', right?

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 6:41 PM
To: Leaf Yeh
Cc: Suresh Krishnan; Ted Lemon; [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Leaf,

> I got a late read on this draft, and may find some editorial nits:
> 
> #1. In sec. 3,
>    "  End-user IPv6 prefix:   The IPv6 prefix assigned to an End-user CE by
>                            other means than MAP itself.  E.g.,
>                            Provisioned using DHCPv6 PD [RFC3633],
>                            assigned via SLAAC [RFC4862], or configured
>                            manually.  It is unique for each CE. "
> 
> Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the subnet ID) in Fig.3?

no, it is e.g. the /56 delegated to the end-user.

> But in sec. 5.2,
> "  The MAP IPv6 address is created by concatenating the End-user IPv6
>    prefix with the MAP subnet identifier (if the End-user IPv6 prefix is
>    shorter than 64 bits) and the interface identifier as specified in
>    Section 6.  "
> 
> Q. Does the above means ' End-user IPv6 prefix ' does not include 's bits' (the subnet ID) in Fig.3? I guess we could include 's bits' (the subnet ID= MAP subnet identifier) into ' End-user IPv6 prefix '.

correct, the subnet-id is not included in the End-user IPv6 prefix.
the End-User IPv6 prefix is the "name" for the address block that the ISP gives to the subscriber.

> And in sec. 6,
> "  If the End-user IPv6 prefix length is larger than 64, the most
>    significant parts of the interface identifier is overwritten by the
>    prefix.  "
> 
> Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the subnet ID) in Fig.3?

still not.

> #2. In sec. 5.1,
> "     For 'a' > 0, A MUST be
>       larger than 0.  This ensures that the algorithm excludes the
>       system ports.  For the default value of a (6), the system ports,
>       are excluded by requiring that A be greater than 0.  Smaller
>       values of a excludes a larger initial range.  E.g., a = 4, will
>       exclude ports 0 - 4095.  The interval between initiaL port numbers
>       of successive contiguous ranges assigned to the same user is
>       2^(16-a).   "
> 
> I prefer the above sentence could be
> "     For 'a' > 0, 'A' MUST be
>       larger than 0.  This ensures that the algorithm excludes the
>       system ports.  Smaller
>       values of 'a' excludes a larger initial range; e.g. 'a' = 4, will
>       exclude ports 0 - 4095.  The interval between initial port numbers
>       of successive contiguous ranges assigned to the same user is
>       2^(16-a).   "

I agree that we should tag 'a'. I'll add that.

> #3. In Fig.7 of sec. 5.3,
> “                   +----------+         +------------+
>                    |IPv4  sufx|         |Port-Set ID |
>                    +----------+         +------------+  ”
> I prefer the above ‘sufx’ could to be ‘suffix’.

ack.

> 
> #4. In sec.6,
> “  The PSID field is left-padded to create a
>    16 bit field.  For an IPv4 prefix or a complete IPv4 address, the
>    PSID field is zero.”
> 
> Q. Does the about ‘zero’ means the value of the PSID=0x 00, or the length of the PSID is zero? I guess it means the former, right?

correct.

> #5. In Fig.8 of sec.6,
> “The Interface identifier format of a MAP node is described below.
>   |          128-n-o-s bits          |
>    | 16 bits|    32 bits     | 16 bits|
>    +--------+----------------+--------+
>    |   0    |  IPv4 address  |  PSID  |
>    +--------+----+-----------+--------+  ”
> 
> I think BR does not need to use the above IID. I prefer to replace the word ‘MAP node’ to be ‘MAP CE’. Right?

correct, but that leads us back to the discussion if the BR should be part of the MAP domain or not. that is should it be possible to reach an address of the BR using IPv4. that's why it says MAP node instead of MAP CE.

> The above format looks like ‘128-n-o-s =64, but that is not always true. I prefer the IID format of MAP CE could be:
>   |          128-n-o-s bits          |
>    | <=16 bits|    32 bits     | 16 bits|
>    +--------+----------------+--------+
>    |   all 0s    |  IPv4 address  |  PSID  |
>    +--------+----+-----------+--------+  ”

whenever we speak about an IPv6 Internet ID it is 64 bits long. I'd rather not that we change that here.
I do see what you are saying though.

> #6. In sec. 8.1,
> “  Secondly, the node extracts the source IPv4
>    address and port from the IPv4 packet embedded inside the IPv6
>    packet.  If they are found to be outside the acceptable range, the
>    packet MUST be silently discard and a counter incremented to indicate
>    that a potential spoofing attack may be underway.”
> 
> I guess the better to substitute the above word ‘embedded’ could be ‘encapsulated’, right?

yes, thanks.

> 
> #7. In sec. 11
> “     They cannot
>       exist with MAP because each BRs checks that the IPv6 source
>       address of a received IPv6 packet is a CE address based on
>       Forwarding Mapping Rule. ”
> 
> I think BRs check that the IPv6 source address of a received IPv6 packet is a CE address based on Basic Mapping Rule, and check that the IPv6 destination address of a received IPv6 packet is a CE address based on Forwarding Mapping Rule, right?

no, the destination IPv6 address is the BR address, and there is no point checking that.

cheers,
Ole

---

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 6 Mar 2015 16:29:47 +0800

Leaf - In sec. 11
>       Forwarding Mapping Rule. ”
Leaf - but my point was 'each BR (note that we don't need 's' here.) checks that whether the IPv6 source address of a received IPv6 packet is a CE address based on Basic Mapping Rule, not Forwarding Mapping Rule.', right?

I withdraw the above question, cause I suppose we don't have BMR (which is for CE) at BR after more times reading of sec.8.1 in the draft . 

But I might get more nits in the Appendix.

#8. In Example 4 of Appendix A, page 26,
"      IPv6 address of MAP CE:  2001:db8:0012:3400:0000:c000:0201:0000
" (the last line)

I suppose it should be “IPv6 address of MAP CE:  2001:db8:0012:3400:0000:c000:0212:0000”

#9. In Example 4 of Appendix A, page 26,
"     …
　　　EA bits offset:       0
      …
      PSID start:           0
      … ”
I don’t think these offset is 0, cause it means the 1st bit of IPv6 address/prefix. I prefer to replace the above ‘0’ to be ‘n/a’.

#10. In Example 5 of Appendix A, page 27,
"     Note that the IPv4 address and PSID is not derived from the IPv6
      prefix assigned to the CE, but provisioned separately using
      e.g., DHCP. "

I guess we don't need this special note here, cause we use DHCPv6 options to provision the Rules, including OPTION_S46_RULE & OPTION_S46_PORTPARAMS as the same manner as example 1 & 4. OTOH, IPv4 address can be directly read from the Rules, and don't need the further calculation as the same as Example 4, but we need OPTION_S46_PORTPARAMS for PSID.

#11. In Example 5 of Appendix A, page 27,
" Basic Mapping Rule:   {2001:db8:0012:3400::/56 (Rule IPv6 prefix),
                             192.0.2.18/32 (Rule IPv4 prefix),
                             0 (Rule EA-bits length)}
      PSID length:          8. (From DHCP. Sharing ratio of 256)
      PSID offset:          6  (Default)
      PSID       :          0x34 (From DHCP.)"

I guess we don’t the above words of 'from DHCP', cause all the parameters in BMR are got from DHCPv6 options.

#12. In Example 5 of Appendix A, page 27,
"      EA bits offset:        0"

Again, I prefer the above to be " EA bits offset:        n/a"

#13.   In Appendix B,
"  o  It SHOULD be possible to exclude subsets of the complete port
      numbering space from assignment.  Most operators would exclude the
      system ports (0-1023).  A conservative operator might exclude all
      but the transient ports (49152-65535).
...
   o  i ranges from ceil(N / (R * M)) to trunc(65536/(R * M)) - 1, where
      ceil is the operation of rounding up to the nearest integer and N
      is the number of ports (e.g., 1024) excluded from the lower end of
      the range."

I guess we could use another parameter 'L' (which could be divisible by R*M) instead of 65536 to exclude the upper end of port-range, while keep to meet those requirement mentioned in Appendix B. Right?

#14. Fig.9 in Appendix B looks the same as Fig. 2 in Sec. 5.1, could we replace 'A' in Fig.2 to be 'i', and replace 'M' in Fig.2 to be 'j'?

Best Regards,
Leaf

-----Original Message-----
From: Leaf Yeh [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2015 4:48 PM
To: 'Ole Troan'
Cc: 'Suresh Krishnan'; 'Ted Lemon'; [email-masked]'
Subject: RE: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

I got it.

Leaf > #4. In sec.6,
Ole - correct.

Leaf > #7. In sec. 11

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 6:41 PM
To: Leaf Yeh
Cc: Suresh Krishnan; Ted Lemon; [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Leaf,

still not.

ack.

correct.

yes, thanks.

cheers,
Ole

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 7 Mar 2015 00:36:24 +0800

I guess we don’t need the above words of 'from DHCP', because all the parameters in BMR are got from DHCPv6 options. And all the above could be parameters in BMR. So it could be written as: 

Basic Mapping Rule:   {2001:db8:0012:3400::/56  (Rule IPv6 prefix),
                     192.0.2.18/32  (Rule IPv4 prefix),
                     0 (Rule EA-bits length)
                     6  (PSID offset, Default)
                     8  (PSID length, Sharing ratio of 256)
                     0x34  (PSID) }

per the definition of OPTION_S46_RULE & OPTION_S46_PORTPARAMS in draft-ietf-softwire-map-dhcp.

Best Regards,
Leaf

-----Original Message-----
From: Leaf Yeh [mailto:[email-masked]] 
Sent: Friday, March 06, 2015 4:30 PM
To: 'Ole Troan'
Cc: 'Suresh Krishnan'; 'Ted Lemon'; [email-masked]'
Subject: RE: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Leaf - In sec. 11

#13.   In Appendix B,

Best Regards,
Leaf

-----Original Message-----
From: Leaf Yeh [mailto:[email-masked]] 
Sent: Tuesday, March 03, 2015 4:48 PM
To: 'Ole Troan'
Cc: 'Suresh Krishnan'; 'Ted Lemon'; [email-masked]'
Subject: RE: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

I got it.

Leaf > #4. In sec.6,
Ole - correct.

Leaf > #7. In sec. 11

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Friday, February 20, 2015 6:41 PM
To: Leaf Yeh
Cc: Suresh Krishnan; Ted Lemon; [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Leaf,

still not.

ack.

correct.

yes, thanks.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Mar 2015 20:31:19 +0100

Leaf,

> per the definition of OPTION_S46_RULE & OPTION_S46_PORTPARAMS in draft-ietf-softwire-map-dhcp.

I see your point. if I remember correctly the “From DHCP” text was put there to emphasise that the PSID isn’t coming from the EA bits.

we could go either way here. since we are so late in the process I’ll take a conservative approach and suggest we keep the current text.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Mar 2015 20:58:11 +0100

Leaf,

> I suppose it should be “IPv6 address of MAP CE:  2001:db8:0012:3400:0000:c000:0212:0000”

sorry, I can’t see what the difference between the two?

> I don’t think these offset is 0, cause it means the 1st bit of IPv6 address/prefix. I prefer to replace the above ‘0’ to be ‘n/a’.

right, there isn’t a PSID in example 4. that’s what n/a, null, 0, 0 is meant to indicate. we could have dropped including anything about the PSID in the example, but we did to contrast it with the address sharing case.

> I guess we don't need this special note here, cause we use DHCPv6 options to provision the Rules, including OPTION_S46_RULE & OPTION_S46_PORTPARAMS as the same manner as example 1 & 4. OTOH, IPv4 a…

again, we wanted to be explicit with regards to the PSID and point out how it contrasts with the other examples.

> I guess we don’t the above words of 'from DHCP', cause all the parameters in BMR are got from DHCPv6 options.

ref, previous mail.

> I guess we could use another parameter 'L' (which could be divisible by R*M) instead of 65536 to exclude the upper end of port-range, while keep to meet those requirement mentioned in Appendix B. R…

probably, but I don’t want to invent any new algorithm at this point. ;-)

> #14. Fig.9 in Appendix B looks the same as Fig. 2 in Sec. 5.1, could we replace 'A' in Fig.2 to be 'i', and replace 'M' in Fig.2 to be 'j’?

I don’t think you can do that. Xing can you confirm?
looking through Appendix B it would seem that would require quite a lot of changes to how M, R, i and j are used.
the purpose of Appendix B was to give a different freestanding angle to the port mapping algorithm.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Mar 2015 21:30:00 +0100

Leaf,

> I suppose it should be “IPv6 address of MAP CE:  2001:db8:0012:3400:0000:c000:0212:0000”

sorry it is getting late here. Ted made me take another look. you are absolutely right.
192.168.0.18 maps to c000:0212 not c000:0201.

I’ll get that fixed.

cheers,
Ole

---

From: Xing Li <[email-masked]>
Date: Sat, 07 Mar 2015 08:32:17 +0800

> I don’t think you can do that. Xing can you confirm?

I confirm to keep the current notation.

Fig.2 is for the specification of the map-e, while Fig.9 is a more 
general discussion of the algorithm (Appendix B and Appendix B.1). 
Capital letters are for the Constants, while Lower cases are for the 
Variables.
> the purpose of Appendix B was to give a different freestanding angle to the port mapping algorithm.

I agree.

Regards,

xing

> cheers,
> Ole
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 9 Mar 2015 11:05:42 +0800

Xing - Capital letters are for the Constants, while Lower cases are for the Variables.

When we read Fig.2 in sec. 5.1, it is about port-set mapping.  
When we talk about the bit representation of a specific port-set, only the PSID part, i.e. k-bits, can be regarded as 'the constant', but the 'A' and 'M' fields in Fig.2 are always variable for the any specific port-set.

Xing - looking through Appendix B it would seem that would require quite a lot of changes to how M, R, i and j are used.

In Appendix B, 'M' stands for the number of contiguous ports in port-set, i.e. M = 2^m, but in Fig.2, 'M' seems stands for the field of m-bits, or the value of the m-bits. 
If we use 'j' substitute 'M' in Fig.2, then the field will definitely mean the value of the m-bits, and has no conflict with the meaning of 'M' in Appendix B.

Xing - the purpose of Appendix B was to give a different freestanding angle to the port mapping algorithm.

I regard the standing of Appendixes in RFC is designed for the better understanding of the text in the main body of proposed standard. 
In my personal and humble opinion, they are not necessary to provide 'a different freestanding angle'.

Best Regards,
Leaf

------------------------------------------------------------
From: Xing Li [mailto:[email-masked]] 
Sent: Saturday, March 07, 2015 8:32 AM
To: Ole Troan
Cc: Leaf Yeh; [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Ole Troan 写道: 

Fig.2 is for the specification of the map-e, while Fig.9 is a more general discussion of the algorithm (Appendix B and Appendix B.1). Capital letters are for the Constants, while Lower cases are for the Variables.

I agree.

Regards,

xing

cheers,
Ole

________________________________________

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 9 Mar 2015 11:25:56 +0800

Ole - that’s what n/a, null, 0, 0 is meant to indicate.

Null !=0, right?

Ole - again, we wanted to be explicit with regards to the PSID and point out how it contrasts with the other examples.

But the same words on the 'IPv4 address and PSID' looks a little vague. The difference between example 4 & 5 is only about the PSID part.

Ole - probably, but I don’t want to invent any new algorithm at this point. ;-)

I haven't propose any new algorithm other than the GMA defined in Appendix. 
I just hope we could drop more words on how to use it better.

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Saturday, March 07, 2015 3:58 AM
To: Leaf Yeh
Cc: Suresh Krishnan; Ted Lemon; [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Leaf,

ref, previous mail.

cheers,
Ole

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 9 Mar 2015 15:58:04 +0800

#15.  One more question,

in Fig.2 of sec. 5.1 & Fig.9 of sec. B.1, the draft uses k-bits to stand for the field of PSID,
but in Fig.6 of sec.5.2 & Fig.7 of sec.5.3, the draft uses q-bits to stand for the field of PSID,

why don't we use the same name, k-bits or q-bits, for PSID?

Best Regards,
Leaf

-----Original Message-----
From: Leaf Yeh [mailto:[email-masked]] 
Sent: Monday, March 09, 2015 11:26 AM
To: 'Ole Troan'
Cc: 'Suresh Krishnan'; 'Ted Lemon'; [email-masked]'
Subject: RE: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Null !=0, right?

Best Regards,
Leaf

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Saturday, March 07, 2015 3:58 AM
To: Leaf Yeh
Cc: Suresh Krishnan; Ted Lemon; [email-masked]
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt

Leaf,

ref, previous mail.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Mar 2015 09:08:58 +0100

Leaf,

> why don't we use the same name, k-bits or q-bits, for PSID?

we could have. I can’t recall now, why we chose to use a different tag for the field in the BMR.
I don’t want to take the risk of changing it.
I hope to get -13 published with some of your other corrections and another clarification from Ian. the dead line for that is today.  then if Ted approves the changes he will pass it onto the RFC Editor.

cheers,
Ole