Re: [Softwires] ISP CGN logging inc. Destination ??

[ianfarrer]

Hi,

As another data point on this topic, the storing of A+P data is also mandated 
in Hungary. From the Hungary paragraph of the 2016 EU report into 
implementation of the Data Retention Directive 
(http://fra.europa.eu/en/theme/information-society-privacy-and-data-protection/data-retention):

"The new law obliges electronic and IT service providers that allow encrypted 
communication through their services to store all metadata related to such 
communications for one year. It thus widens the scope of data retention."

Translated: A+P retention.

Cheers,
Ian


> 

> PS: Few may be aware of Govt. of India’s mandate* to log both source and 
> destination IP+port pair.
> Click on “Parameter to be stored in SYS Log of Network Address Translation 
> (NAT) for Internet Access” on this page - 
> https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/
>  
> 
>  
> PS: 
> https://tools.ietf.org/html/rfc6302 
> https://tools.ietf.org/html/rfc7422 
>  
>  
> Session and service continuity
> ___
> Softwires mailing list
> Softwires@ietf.org 
> https://www.ietf.org/mailman/listinfo/softwires 
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[ianfarrer]

Hi Bernie,

Thanks. I’ll still with 3315bis for now then.

BTW - I’ve added another paragraph to the Sec. Considerations section reading:

   A client may attempt to overload the server by sending multiple
   source address update messages (see Section 7.2.1) in a short time
   frame.  This risk can be reduced by implementing a server policy
   enforcing a minimum time interval between client address changes as
   described in Section 8.1.

DOS prevention was the reason for including the minimum time in the first 
place, so I think it makes sense to list it here.

Cheers,
Ian

> On 8. May 2018, at 16:39, Bernie Volz (volz)  wrote:
> 
> Hi Ian:
>  
> Thanks … suggested text changes look good. I would think it best to reference 
> 3315bis … hopefully it won’t hold up publication of this draft since it may 
> take RFC Editor a bit longer to process the 3315bis document, but they also 
> will have a head start. (If it does hold it up and we need to expedite 
> release of this draft as an RFC, we can always ask for reference to change to 
> 3315.)
>  
> Bernie
>  
> From: Ian Farrer 
> Date: Tuesday, May 8, 2018 at 10:10 AM
> To: Bernie Volz 
> Cc: "dh...@ietf.org" , 
> "draft-ietf-dhc-dhcp4o6-saddr-...@ietf.org" 
> , "softwires@ietf.org" 
> 
> Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - 
> EXTENDED - Respond by April 17, 2018
>  
> Hi Bernie,
>  
> Many thanks for the review. I’ve had a look through your comments and they 
> all look straightforward enough. They will be in the next version with 
> Tomek’s comments.
>  
> Here’s my suggestions in response to a couple of your comments:
>  
> SECTION 9:
>  
> -  More of a question – do the new options or procedures add any new 
> or different considerations? If not, great.
>  
> There is one case that I think is missed. I’ve update the Security 
> Considerations section to add the following text:
>  
>   A rogue client could attempt to use the mechanism described
>   in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 
> traffic
>   intended for another client to itself. This would be performed by
>   sending a DHCPREQUEST message for another client's active IPv4
>   lease containing the attacker's softwire IPv6 address in
>   OPTION_DHCP4O6_S46_SADDR.
> 
>   For such an attack to be effective, the attacker would
>   need to know both the client identifier and active IPv4
>   address lease currently in use by another client. The risk
>   of this can be reduced by using a client identifier format 
>   which is not easily guessable, e.g. by including a time 
>   component for when the client identifier was generated
>   (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).
>  
>  
>> -  And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 
>> (draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are 
>> implicit because RFC7341 is referenced, but not always clear that this is 
>> the best way to go. But I didn’t find any easy way to incorporate these 
>> references directly.
>  
> I’ve added the following to Section 4. Solution Overview:
>  
> In order to provision a softwire, both IPv6 and IPv4 configuration
> needs to be passed to the client. To map this to the DHCP 4o6
> configuration process, the IPv6 configuration is carried in
> DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried
> inside the DHCPv6 message DHCPV4-RESPONSE (21) 
> sent by the server.
>  
> And:
>  
> IPv4 configuration is carried in DHCPv4 messages ,
> (inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
> described in .
>  
> The normative refs. are updated with these as well.
>  
> BTW, should I be referencing RFC3315 or the -bis version as normative at this 
> stage?
>  
> Thanks,
> Ian
>  

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] ISP CGN logging inc. Destination ??

[ianfarrer]

Hi Jordan,

Please see inline below.

Thanks,
Ian

> On 9. May 2018, at 21:38, Gottlieb, Jordan J  
> wrote:
> 
> If I understand this correctly it appears that requirement #1 would dictate 
> the capability must be deployed on the CE.  The way I read it you are 
> attempting to retain the pre-NAPT client address and port.  For the 
> particular use case, is the CPE managed by the service provider?  If so, why 
> not originate the logging from the CPE as it has the necessary visibility and 
> state maintenance to meet all the requirements?

[if – This is a possibility in some networks, but in many countries (most of 
Europe AFIAK], SP’s must allow customers to attach their own equipment so this 
can’t be considered a secure device for meeting data retention regulations.]

>  
> There was also a comment in this thread regarding UDP and session completion. 
>  I don’t think this is practical on the BR as support for asymmetrical 
> routing could result in incomplete session information on a particular BR 
> (you would have to piece it together) as exit transit BR could be different 
> from the return transit BR.  The only device with a complete view of the flow 
> is the CE in this case as well.

[if – I agree that the collection is complicated if you have multiple BRs, but 
as stated above, I don’t see the CE being a viable solution for many 
deployments.]

>  
> Assuming CPE is not an option, MAP-T , and that requirement #1 is not the 
> privately addressed customer endpoint (laptop, tablet, smartphone, etc..) one 
> could use netflow pre-BR (IPv6) and some simple program to convert to the 
> required metadata.  Destination address is trivial as it is a fixed set of 
> bits within the DMR(s).  Source address is not hard as long as the conversion 
> program has an accurate list of active mapping rules.  Obviously sampling 
> rate comes into play but I believe we have the same issue with IPFIX.

[if - I’m not sure I follow this proposal. Would the pre-BR device still 
identify flows, just at a different offset within the header? Would the 
metadata conversion take place on the same device?]


>  
> Cheers,
>  
> Jordan
>  
> From: Softwires [mailto:softwires-boun...@ietf.org 
> ] On Behalf Of 
> mohamed.boucad...@orange.com 
> Sent: Wednesday, May 09, 2018 1:31 AM
> To: Rajiv Asati (rajiva); ramesh.r.chan...@ril.com 
> ; yiu_...@comcast.com 
> 
> Cc: softwires@ietf.org ; int-a...@ietf.org 
> 
> Subject: Re: [Softwires] ISP CGN logging inc. Destination ??
>  
> Hi Rajiv,
>  
> What concerns me with this requirement is that it nullifies one of the 
> motivations for stateless address sharing:
> https://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-3.1.3
>  
> (Logging
>  - No Need for Dynamic Binding Notifications)
>  
> especially, this part:
>  
>Some Service Providers have a requirement to use only existing
>logging systems and to avoid introducing new ones (mainly because of
>Capital Expenditure (CAPEX) considerations).  This requirement is
>easily met with stateless solutions.
>  
> Cheers,
> Med
>  
> De : Softwires [mailto:softwires-boun...@ietf.org 
> ] De la part de Rajiv Asati (rajiva)
> Envoyé : mardi 8 mai 2018 23:43
> À : ramesh.r.chan...@ril.com ; 
> yiu_...@comcast.com 
> Cc : softwires@ietf.org ; int-a...@ietf.org 
> 
> Objet : Re: [Softwires] [EXTERNAL] Re: ISP CGN logging inc. Destination ??
>  
> Agree with Ramesh. DHCP(v6) helps with logging source IP assignment, but 
> that’s it.
> 
> The requirement here is about keeping track of not only source IP+port, but 
> also destination IP+port per connection. DHCP(v6) doesn’t apply here.
>  
> -- 
> Cheers,
> Rajiv  
>  
> From: "ramesh.r.chan...@ril.com " 
> >
> Date: Tuesday, May 8, 2018 at 1:15 AM
> To: "yiu_...@comcast.com "  >
> Cc: "ianfar...@gmx.com "  >, Rajiv Asati  >, Softwires-wg list  >, "int-a...@ietf.org " 
> >
> Subject: RE: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??
>  
> Not really. Need IPv4 because desitination IP is on IPv4. <>
>  
> Regds
> ramesh chandra
> M#: +91 90829 61303
> O#: +91 22 7965 9762
>  
> 

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[ianfarrer]

Hi Bernie,

Many thanks for the review. I’ve had a look through your comments and they all 
look straightforward enough. They will be in the next version with Tomek’s 
comments.

Here’s my suggestions in response to a couple of your comments:

SECTION 9:
 
-  More of a question – do the new options or procedures add any new or 
different considerations? If not, great.

There is one case that I think is missed. I’ve update the Security 
Considerations section to add the following text:

  A rogue client could attempt to use the mechanism described
  in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 
traffic
  intended for another client to itself. This would be performed by
  sending a DHCPREQUEST message for another client's active IPv4
  lease containing the attacker's softwire IPv6 address in
  OPTION_DHCP4O6_S46_SADDR.

  For such an attack to be effective, the attacker would
  need to know both the client identifier and active IPv4
  address lease currently in use by another client. The risk
  of this can be reduced by using a client identifier format 
  which is not easily guessable, e.g. by including a time 
  component for when the client identifier was generated
  (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).


> -  And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 
> (draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are 
> implicit because RFC7341 is referenced, but not always clear that this is the 
> best way to go. But I didn’t find any easy way to incorporate these 
> references directly.

I’ve added the following to Section 4. Solution Overview:

In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in
DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried
inside the DHCPv6 message DHCPV4-RESPONSE (21) 
sent by the server.

And:

IPv4 configuration is carried in DHCPv4 messages ,
(inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in .

The normative refs. are updated with these as well.

BTW, should I be referencing RFC3315 or the -bis version as normative at this 
stage?

Thanks,
Ian

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] ISP CGN logging inc. Destination ??

[ianfarrer]

Hi Rajiv,

Please see inline.

Cheers,
Ian

> On 4. May 2018, at 12:01, Rajiv Asati (rajiva)  wrote:
> 
> Ian,
> 
> Thanks for sharing the URL. While not explicit, “all metadata” would include 
> both source and destination A+P. Is that the right interpretation?

[if - My understanding is that per-flow logging is necessary to meet the 
requirement, but I’m not familiar enough with the legislation to know what 
exactly needs to be stored.]

> 
> If an ISP were to use “binding” mode on the BR, then without using net 
> flow/IPFIX, How could the compliance be achieved ?

[if - If there’s address sharing and the requirement is to provide an exact 
match to a data retention request (in some countries, a list of e.g. 16 users 
is OK), then AFAICS, you have to use IPFIX.

The implementation problem for this is compounded by the lack of state table on 
most BR implementations (e.g. how do you know when a UDP session has completed 
without state for that flow?)]

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Review of draft-ietf-softwire-mesh-multicast-20

[ianfarrer]

Hi,

I’ve just done a final review of -v20 of the draft. There’s still a few 
linguistic points and some clean ups that I think are needed. 

There’s also a couple of comments regarding points I would expect to get raised 
in later review phases, so it would be good if we could resolve these in 
advance.

Please see below.

Thanks,
Ian



Section 1.1
The paragraph beginning ‘Figure 1 shows…’ through to the end of the section 
shouldn’t be located under Requirements Language. Please move to Section 1.

Figure 1
Please use this cleaned up version of the diagram:


+-++-+
| || |  ++
|  E-IP   ||  E-IP   +—-+Source S|
| Network || Network |  ++
++++——+--+
 ||
  +--+---+  +-++
  |  |  | Upstream |
+-|   AFBR   +--+   AFBR   |-+
| +--+  +--+ |
||  E-IP Multicast
|  I-IP transit core |  packets are forwarded
||  across the I-IP
| +--+  +--+ |  transit core
+-+Downstream+--+Downstream+-+
  |   AFBR   |  |   AFBR   |
  +--+---+  +---+--+
 |  |
++++++
++  | || |  ++
|Receiver+--+  E-IP   ||  E-IP   +--+Receiver|
++  | Network || Network |  ++
+-++-+


Figure 2.
Please use this cleaned up version of the diagram:
+-++-+
|  IPv4   ||  IPv4   |  ++
| Client  || Client  |--+Source S|
| Network || Network |  ++
++++++
 |  |
  +--+---+  +---+--+
  |  |  | Upstream |
+-+   AFBR   +--+   AFBR   |-+
| +--+  +--+ |
||
|  IPv6 transit core |
||
| +--+  +--+ |
+-+Downstream+--+Downstream+-+
  |   AFBR   |  |   AFBR   |
  +--+---+  +---+--+
 |  |
++++++
++  |  IPv4   ||  IPv4   |  ++
|Receiver+--+ Client  || Client  +--+Receiver|
++  | Network || Network |  ++
+-++-+

4.1.  Mechanism Overview
s/and is certainly separated from E-IP multicast state./and is separated from 
E-IP multicast state./
The word ‘certainly’ doesn’t really make sense here.

4.3. Source Address Mapping
Suggested reword for readability and to fix ‘WildCare’ spelling: 
o E-IP network supports ASM
  The (S,G) source list entry and the (*,G) source list entry differ
  only in that the latter has both the WildCard (WC) and RPT bits
  of the Encoded-Source-Address set, while with the former, the bits
  are cleared (See Section 4.9.5.1 of [RFC7761]).  As a result, the
  source list entries in (*,G) messages can be translated into source list
  entries in (S',G') messages by clearing both the WC and RPT bits
  at downstream AFBRs, and vice-versa for the reverse translation at
  upstream AFBRs.
——

I-D Nits is complaining about the group address word spacing in the figure.
Please use the following for figure 3:
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 | 0-32--40--48--56--64--72--80--88--96---127|
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 |mPrefix46  | group address |
 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
---
4.4 Routing Mechanism
The following sentence is a a little unclear:
Since every IP address of upstream AFBR's E-IP interface is different from each 
other, every uPrefix46 that AFBR announces MUST be different.
Can it be simplified just to say?:
Every uPrefix46 that an AFBR announces MUST be unique.

Suggest that a paragraph break is inserted between ‘mesh unicast scenario.’ and 
‘But as the “v4” field’ and that the word ‘But’ is removed.
——
s/BGP messages that are carried over I-IP, whose NLRI and NH are of E-IP 
address family./BGP messages that are carried over the I-IP, and whose NLRI and 
NH are of the E-IP address family./
—
5.2. I-IP (S’,G’) State Maintenance
s/It is possible that the I-IP 

Re: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-21.txt

[ianfarrer]

Hi,

Thanks for the update. There’s one of the review comments that got missed. Can 
you fix?

Thanks,
Ian

6.4. Inter-AFBR Signalling

s/Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT of 
(S,G)/Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT of 
(S,G)/

> On 3. Jun 2018, at 19:43, Shu Yang  wrote:
> 
> Hi folks,
> 
> We have submitted a new version of the draft "IPv4 Multicast over an IPv6 
> Multicast in Softwire Mesh Network" 
> (https://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-21 
> ).
> 
> Your comments are welcomed!
> 
> Shu Yang
> 
> On Sat, Jun 2, 2018 at 7:40 AM,  > wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Softwires WG of the IETF.
> 
> Title   : IPv4 Multicast over an IPv6 Multicast in Softwire 
> Mesh Network
> Authors : Mingwei Xu
>   Yong Cui
>   Jianping Wu
>   Shu Yang
>   Chris Metz
> Filename: draft-ietf-softwire-mesh-multicast-21.txt
> Pages   : 19
> Date: 2018-06-01
> 
> Abstract:
>During the transition to IPv6, there will be scenarios where a
>backbone network internally running one IP address family (referred
>to as the internal IP or I-IP family), connects client networks
>running another IP address family (referred to as the external IP or
>E-IP family).  In such cases, the I-IP backbone needs to offer both
>unicast and multicast transit services to the client E-IP networks.
> 
>This document describes a mechanism for supporting multicast across
>backbone networks where the I-IP and E-IP protocol families differ.
>The document focuses on IPv4-over-IPv6 scenario, due to lack of real-
>world use cases for IPv6-over-IPv4 scenario.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/ 
> 
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-21 
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-mesh-multicast-21 
> 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-mesh-multicast-21 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org 
> .
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ 
> 
> ___
> Softwires mailing list
> Softwires@ietf.org 
> https://www.ietf.org/mailman/listinfo/softwires 
> 
> 

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] IPR Poll for draft-ietf-softwire-mesh-multicast

[ianfarrer]

Hi Authors,

Please reply to this email including the mailing list indicating whether
you are aware of any IPR related to draft-ietf-softwire-mesh-multicast.

Thanks,
Ian

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Further draft-ietf-softwire-mesh-multicast

[ianfarrer]

Hi Authors,

I’m currently in the process of doing the write up for the draft. Please can 
you tell me if there are there any implementations in existence?

Also, I have run v21 through ID-Nits. The important output is below. For the 
downref, to RFC4925, does this need to be a normative reference?

Please can you address these points and submit an updated version.

Thanks,
Ian


  Checking references for intended status: Proposed Standard
  

 (See RFCs 3967 and 4897 for information about using normative references
 to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC4291' is defined on line 677, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC4301' is defined on line 681, but no explicit
 reference was found in the text

  == Unused Reference: 'RFC7371' is defined on line 732, but no explicit
 reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 4925

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Result//RE: WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

[ianfarrer]

Hi Sheng,

Thank you for the summary below. I believe that -06 addresses all of the 
comments received during the WGLC. Please let me know if there is anything 
outstanding.

Best regards,
Ian 

> On 2. Jul 2018, at 03:43, Sheng Jiang  wrote:
> 
> Hi, all, 
> 
> We received no negative response to the WGLC on draft-ietf-softwire-yang-04 
> during the two-week WGLC and we did receive good reviews through the WG 
> document stage, through the shepherd review process and WGLC period. The 
> authors have provided 06 version, which have addressed most, if not all, of 
> received comments. Considering the past history of this work, I, as the 
> document shepherd, feel it has passed the WGLC and should advance.
> 
> Up to now, there is no IPR disclosure to this document.
> 
> Best regards,
> 
> Sheng (shepherd, both chair Yong Cui and Ian Farrer who as a co-author stayed 
> neutral on the content side)
> 
>  
> From: Softwires [mailto:softwires-boun...@ietf.org 
> ] On Behalf Of Sheng Jiang
> Sent: Wednesday, June 27, 2018 12:00 PM
> To: Softwires WG mailto:softwires@ietf.org>>
> Cc: softwire-cha...@ietf.org 
> Subject: Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard 
> Track, closed by 27 June 2018
>  
> As the document shepherd, I have reviewed this document. Document editors and 
> WG chairs should treat these comments just like any other last call comments. 
> In general, I think this document is in a good shape. The YANG model is well 
> defined and clearly described.
> Here are some minor issues, mostly editorial, although there is 1 error 
> report by the IETF Yang validation tool. It should be easy to be fixed, I 
> blieve
>  
> There are some minor comments below, most of them are editorial.
>  
> Section 2.1
> It may be better to add the statement names in the description of choice 
> statement:
>   a choice statement 'ce-type' is included for ...
>   a choice statement 'data-plane' is included to ...
>  
> "For each module, a choice statement is included for either 'binding' or 
> 'algorithmic'."
> But in Table 1 it is 'algorithm'. Maybe 'algorithmic' should be changed to 
> 'algorithm'.
>  
> Section 2.2
> The reference to Appendix A.3 should be Appendix A
>  
> Section 3.1
> "for all of the softwire mechanisms listed in Section 1"
> It may be bette to avoid self citation and just list the mechanisms here.
>  
> "Figure 1 describes the tree structure of the CE softwire YANG module"
> It's better to unify the terminology as "Softwire CE YANG Module"
>  
> Section 3.2
> In the paragraph of "softwire-path-mru:":
> It's confusing here whether the MRU is for IPv4 or IPv6.
>  
> There are two "br-ipv6-addr" defined. It may be better to add different 
> prefixes or suffixes into the names, but I'm also OK with the current names...
>  
> In the paragraph of "ce-binding-ipv6-addr-change:":
> "binding-ipv6-address" is not defined in the whole document. It should be 
> explained.
>  
> Section 4.2
> "in Figure 1"
> should be "in Section 3.2"
>  
> "for logging/data retention purposes" -> "for logging or data retention 
> purposes"
>  
> "between 3-tuples, which contains the lwB4's IPv6 address..." -> "between 
> 3-tuples: the lwB4's IPv6 address..."
>  
> "softwire-num-threshold"
> From the description, I think it may be better to rename it to 
> "softwire-num-max".
> In the paratraph of "invalid-entry, added-entry, modified-entry:":
> "the client" -> "the NETCONF client"
>  
> Appendix A.1
> "lwB4 IPv6 Address:  123"
> What's the "lwB4 IPv6 Address" here?
>  
> Appendix A.2 
> "for the clients" -> "for the CEs"
>  
> Appendix A.3
> The same "lwB4 IPv6 Address" issue
> And the PSID and PSID offset should be provided in the example.
>  
> Cheers,
>  
> Sheng
>  
> From: Softwires [mailto:softwires-boun...@ietf.org 
> ] On Behalf Of Sheng Jiang
> Sent: Wednesday, June 13, 2018 5:44 PM
> To: Softwires WG mailto:softwires@ietf.org>>
> Cc: softwire-cha...@ietf..org 
> Subject: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, 
> closed by 27 June 2018
>  
> This email announces a Softwire Working Group Last Call (WGLC) on:
>  
> Since both chairs of softwire WG are the co-authors of this document. I am 
> now acting as the document shepherd for this draft.
>  
> YANG Modules for IPv4-in-IPv6 Address plus Port Softwires 
> draft-ietf-softwire-yang-04
> https://tools.ietf.org/html/draft-ietf-softwire-yang-04 
> 
>  
> This draft is intended to become a Standard Track RFC.
>  
> This WGLC will run through the end of the day on Wednesday, June 27, 2018.
>  
> Comments should be sent to the softwires@ietf.org  
> list, although purely
> editorial comments may be sent directly to the author.
>  
> No IPR disclosures have been submitted directly 

Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

[ianfarrer]

Hi Sheng /Med,

@Sheng, Thanks for the review.
@Med, Thanks for the quick update.

A couple of other things:

There’s an outstanding comment on model element descriptions given as “…”. 
Proposed new text:

notification softwire-binding-instance-event description: "The ID of the 
binding-instance that generated the notification.";

leaf-list modified-entry description "The ID of the the binding-table entry 
that has been modified.";

--
I just did a quick read through of -05. There are a few small language cleanups 
that I would like to make:

Section 2.1
s/Provides configuration and monitoring for softwire CE element/Provides 
configuration and monitoring for the softwire CE element/

s/Provides configuration and monitoring for softwire BR element/Provides 
configuration and monitoring for the softwire BR element/

Section 2.2
s/be imported here, as needed/be imported, as needed/

ietf-softwire-ce:binding-entry/br-ipv6-addr
description
s/The IPv6 address for of the binding BR./The IPv6 address for the binding BR./

ietf-softwire-br:br-instances/algorithm
description
s/Indicate that the instance supports the MAP-E and MAP-T functions./Indicate 
that the instance supports the MAP-E and MAP-T functions./

If there’s no objection to the above changes, I’ll update and post later on 
today.

Cheers,
Ian

> On 27. Jun 2018, at 10:54, mohamed.boucad...@orange.com wrote:
> 
> Hi Sheng,
>  
> Many thanks for the careful review.
>  
> An updated version which integrates your comments is available 
> online:https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1
>  
>  
> See more inline.
>  
> Cheers,
> Med
>  
> De : Softwires [mailto:softwires-boun...@ietf.org 
> ] De la part de Sheng Jiang
> Envoyé : mercredi 27 juin 2018 06:00
> À : Softwires WG
> Cc : softwire-cha...@ietf.org 
> Objet : Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard 
> Track, closed by 27 June 2018
>  
> As the document shepherd, I have reviewed this document.. Document editors 
> and WG chairs should treat these comments just like any other last call 
> comments. In general, I think this document is in a good shape. The YANG 
> model is well defined and clearly described.
> Here are some minor issues, mostly editorial, although there is 1 error 
> report by the IETF Yang validation tool. It should be easy to be fixed, I 
> believe
>  
> [Med] As you can see in 
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/softwire-yang-validation.pdf
>  
> ,
>  the module passes validation. The issue displayed by the tracker is related 
> to iana-if-t...@2018-06-22.yang 
> .
>  
> There are some minor comments below, most of them are editorial.
>  
> Section 2.1
> It may be better to add the statement names in the description of choice 
> statement:
>   a choice statement 'ce-type' is included for ...
>   a choice statement 'data-plane' is included to 
>  
> [Med] Fixed.
>  
> "For each module, a choice statement is included for either 'binding' or 
> 'algorithmic'."
> But in Table 1 it is 'algorithm'. Maybe 'algorithmic' should be changed to 
> 'algorithm'.
>  
> [Med] Good catch. Fixed.
>  
>  
> Section 2.2
> The reference to Appendix A.3 should be Appendix A
>  
> [Med] Citing Appendix A.3 is on purpose. It is where NAT and RFC8349 examples 
> are provided.
>  
>  
> Section 3.1
> "for all of the softwire mechanisms listed in Section 1"
> It may be bette to avoid self citation and just list the mechanisms here.
>  
> [Med] OK.
>  
>  
> "Figure 1 describes the tree structure of the CE softwire YANG module"
> It's better to unify the terminology as "Softwire CE YANG Module"
>  
> [Med] OK.
>  
>  
> Section 3.2
> In the paragraph of "softwire-path-mru:":
> It's confusing here whether the MRU is for IPv4 or IPv6..
>  
> [Med] The text indicates “to set the maximum IPv6 softwire packet size”. 
> Furthermore, the description “The path MRU for the softwire (payload + 
> encapsulation
> overhead)” is also clear about the usage. I don’t think a change is 
> required.
>  
> There are two "br-ipv6-addr" defined. It may be better to add different 
> prefixes or suffixes into the names, but I'm also OK with the current names..
> [Med] We could add map or lw prefixes, but as you know adding prefixes is not 
> helpful (and it even not recommended) as a leaf is identified by its parent. 
> I suggest to leave those unmodified. 
>  
> In the paragraph of "ce-binding-ipv6-addr-change:":
> "binding-ipv6-address" is not defined in the whole document. It should be 
> explained.
>  
> [Med] changed to “binding IPv6 address”
>  
> Section 4.2
> "in Figure 1"
> should be "in Section 3.2"
>  
> [Med] OK.
>  
>  
> "for 

[Softwires] Fwd: I-D Action: draft-ietf-softwire-map-radius-16.txt

[ianfarrer]

Forwarding to the list.


Hi Yu,

Thanks for the update. I think the changes that you have made have improved the 
document significantly, but there’s still a few things that need to be 
addressed. Please see below.

Also, Jordi asked a question about this draft, which I don’t think has been 
replied to:
https://mailarchive.ietf.org/arch/msg/softwires/_7ocUxBwy9i2UqNj2tzqri9p0Gw 


Thanks,
Ian

New comments on -16:

Throughout - the use of 'Sub TLV' and 'Sub-TLV' is not consistent.
Sub-TLV seems to be the convention in other RFCs (e.g. RFC6929).

Introduction.

s/At the Section 4.9/In Section 4.9/

As the softwire prioritisation funciton of RFC8026 is also
included, there should be a short paragraph (a cut down version of
sec 4, para 3) stating that this function is included.

Section 3, point 6.

In the diagram, you show a simple reply message being sent
to the client, but the accompanying text describes a number
of other communication flows and updates that can potentially
need to happen.

Really, the whole of this section is not really well constructed
in it's current form. The purpose of the numbered points is to
describe what is in the flows in the diagram, but point 6. goes
on to included a further page and a half of options and
considerations. Can point 6 not be ended after the sentance ending
enumerated in the ORO.? and the remaining text in section 3
be put into relevantly named sub-sections.

4.4.2 S46-BR Sub TLV
S46-Lightweight--4over6 TLV - please remove duplicate '-'.

4.5 Sub-TLVs for S46-Rule Sub TLV
Given the RFC2119 language used in the requirements for the
other options, suggest the following:
s/It should appear for once and only once./It MUST appear
exactly once./

4.6.2 The Bind-IPv6-Prefix Sub-TLV

s/The bind-ipv6-prefix field specified in this field/The bind-ipv6-prefix 
specified in this field/

-

Updated comments from my previous review:


1.f)
After the sentence "A DHCPv6 server function is
  assumed to be embedded in the BNG that allows it to locally handle
  any DHCPv6 requests initiated by hosts." it would be
  worth adding that the term BNG is used througout the document
  to describe a device which functions as both the AAA client
  and DHCPv6 server.

[if - New version is better, but a suggested rewording for these two sentances:
A DHCPv6 server function is assumed to be embedded in the BNG
that allows it to locally handle DHCPv6 requests initiated by
hosts.  The abbrieviation BNG is used in this document to describe a device
which functions as both the AAA client and DHCPv6 sever.]


1.i)
Last paragraph: It would also be worth saying how the structure of the
DHCP options and field namings are preserved so they can
easily be mapped between DHCP and RADIUS.

[if - I can't find any changes in the text for this, or any repsonse
to the comment.]




3.c)
The figure is easier to follow if it is space out a bit more and
clafifies the first step:

 CE BNG AAA Server
 |   |   |
 |---1.DHCPv6 Solicit--->|   |
 |(ORO with unicast and/or m'cast|   |
 |container option code(s))  |   |
 |   |   |
 |   |---2.Access-Request--->|
 |   | (S46-Configuration attribute  |
 |   |and/or S46-Multicast attribute)|
 |   |   |
 |   |<--3.Access-Accept-|
 |   | (S46-Configuration attribute  |
 |   |and/or S46-Multicast attribute)|
 |   |   |
 |<4.DHCPv6 Advertisement|   |
 | (container option(s)) |   |
 |   |   |
 |---5.DHCPv6  Request-->|   |
 | (container Option(s)) |   |
 |   |   |
 |<6.DHCPv6 Reply|   |
 | (container option(s)) |   |
 |   |   |
  DHCPv6 RADIUS

[if - Old diagram is still present, please use the above figure.]


3.f)
Replace:
For the multicast case, OPTION_V6_PREFIX64 should be included for the delivery 
of multicast
  services in the context of transition to IPv6.
with:
For the multicast case, the the option number for OPTION_V6_PREFIX64 (113)
should be included in the client's ORO.

[if - Sorry, 

Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 2 of 2

[ianfarrer]

Hi,

Review part 2.

Cheers,
Ian

-
4. Attributes 
4.a) 'sub options' is used. Conventionally, this is
hypenated as 'sub-options'. Please change throughout.

4.b) It would be more accurate to say:
Different combinations of sub-options are
   required for each type of S46 Container...

4.c)
"  The RADIUS attribute
   for Dual-Stack Lite [RFC6333] is defined in [RFC6519]."

This is the first time in the document that DSLite is referenced.
Would it be better to put a paragraph in the Introduction saying
that this document is not concerned with DSLite/RADIUS as it's 
already covered in RFC6519.

4.c)
The S46 Container Options section describes how the containers and
options are constructed. It would read better to have this overview text
before descrbing the structure of any of the attributes/options.

4.e)
In the description text around Fig.2 a pointer to the table in 4.7
would be helpful. It may actually be better to move the table from
section 4.7 into section 4.2 so they can be compared directly by
the reader.

4.f)
Figure 2 doesn't really make it clear that the relevant (and necessary)
sub-options (numbered 1-5) is decided by which on of the three
S46 container options is being used. This makes it confusing to understand.

As a suggestion, would 3 diagrams (one for each type) structured like this
be more clear showing what is necessary and what is optional?

   / (Mandatory)/1.Rule-IPv6-Prefix
  ||   sub-option
  | 1.S46-Rule + 2.Rule-IPv4-Prefix
  |sub-option  |   sub-option
  || 3.EA Length
 S46 MAP-E Container--+ \  sub-option
  Option  | 2.S46-BR Sub Option
- - - - - - - - - - - - - - - - - - - - - - - - - 
  | (Optional)   /1.PSID-offset
  | |   sub-option
  | 3.S46-PORTPARAMS ---+ 2.PSID-len
  | sub-option  |   sub-option
  | | 3.PSID
   \ \  sub-option

The paragraph begining 'There are three types of S46 Container Options...'
would need to be moved before this for readability.

4.g)
The paragraph begining 'There are three types of S46-Rule Sub Options...'
seems to be in the wrong section. It belongs in 4.3.1.

4.h)
s/The S46-BR Sub Option can only be encapsulated in the MAP-E Container
   Option or the Lightweight 4over6 Container Option./
   The S46-BR Sub Option can only be encapsulated in the MAP-E or 
   Lightweight 4over6 Container Options./

4.i)
4.3.3.  S46-DMR Sub Option
s/set to all zero./set to all zeros./

4.j)
4.3.4. S46-V4V6Bind Sub Option 
s/There MUST be at most one/There MUST be exactly one/

4.k)
4.3.5.  S46-PORTPARAMS Sub Option
Suggest that the first sentance is extended to say:
The S46-PORTPARAMS Sub Option specifies optional port set information
   that MAY be provisioned to CEs to configure sharing of an IPv4 address.

4.l)
Throughout this section, it would be a good idea to put in a pointer
to the section of RFC7598 that the option/sub-option corresponds to.

4.m)
s/The Softwire46-Multicast attribute conveys the IPv6 prefixes to be
   used in [RFC8114] to synthesize IPv4-embedded IPv6 addresses./
   The Softwire46-Multicast attribute conveys the IPv6 prefixes to be
   used to synthesize IPv4-embedded IPv6 addresses as per [RFC8114]./

4.n)
This attribute MAY be used in Access-Request packets as a hint to the
   RADIUS server.  For example, if the BNG is pre-configured with
   Softwire46-Multicast, these prefixes MAY be inserted in the
   attribute.

Is this saying that the attribute could be pre-configured with a
value in the BNG's AAA client meaning that it wouldn't be requested from
AAA, but would be supplied in the DHCP message? Please can you expand
the description. I also wonder if this statement is true for any of
the other attributes described in the document.

4.o)
The definitions of which RADIUS messages types the multicast 
attribute can appear in should also exist for the unicast and priority
attributes.
Update - having read section 4.10, the information is there, but
is duplicated for multicast. One common format for the information
and pointers would be cleaner.

4.p)
The description text and formatting between the 4.2-4.8 options is
inconsistent and should be aligned. Personally, I think the bullet
point list of what is and isn't permitted in section 4.9 is clear
and could be usefully used in 4.2-4.9.

4.q)
4.9.1.  ASM-Prefix64 TLV
The field in the diagram is called 'Prefix-Length', but in the
description, this field is 'Length'. This also needs fixing
in 4.9.2 and 4.9.3

4.r)
4.9.2 & 4.9.3
s/This fiel is reserved./This field is reserved./

4.s)
Section 4.9 uses TBD1 as a placeholder for an IANA assignment. 

Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

[ianfarrer]

Hi,

Here’s my review of the draft. It’s rather long so I’ve had to submit it as two 
emails. It’s based on -15. 

Cheers,
Ian


Title
T.a)
 RADIUS Attribute for Softwire Address plus Port based Mechanisms

 To improve readability and as this defines 3 new RADIUS attributes, 
 'RADIUS Attributes for Address plus Port based Softwire Mechanisms'

-
Abstract:
A.a)
"IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
   connectivity services simultaneously during the IPv4/IPv6 co-existing
   period." 

This isn't really true. The transisition mechanisms don't provide
v6 connectivty, they rely on this being there and working. Suggested re-word:

IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
   connectivity services simultaneously during the IPv4/IPv6 co-existence
   period.
   
A.b)
"The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   options have been defined to configure Customer Edge (CE) in MAP-E,
   MAP-T, Lightweight 4over6 and PREFIX64 option for Multicast Basic
   Bridging BroadBand (mB4) in multicast scenarios. "
   
Suggested re-word for readability: 
   DHCPv6 options have been defined for configuring clients to use MAP-E,
   MAP-T, Lightweight 4over6 and Multicast Basic Bridging BroadBand (mB4) in 
multicast scenarios.  
   

A.c)
The abstract has both the expanded and abbrieviated form of a few terms
(e.g. BNG). These definitions are also repeated later in the introduction.
As these terms are defined in the IETF acronyms list
https://www.rfc-editor.org/materials/abbrev.expansion.txt 

there's no need to provide these definitions, just the acronyms would
be OK. 
As a suggestion for readability - DHCPv6, RADIUS, AAA, and BNG are well
known so don't need the expanded form. mB4 is less well known, so
the expanded version is more helpful.
The repetitions of the definitions in the Introduction can be removed.

A.d)
"This document defines two new Remote Authentication Dial In User
   Service (RADIUS) attributes that carry CE or mB4 configuration
   information from an AAA server to BNG."

There's actually 3 new attributes in the draft (Softwire46-Priority
is missing).


--

1. Introduction
1.a)
It would simplify the overall readibility of the document
to define the MAP-E, MAP-T and lw4o6 (i.e. RFC7598 configured)
softwires as 'unicast' and the RFC8114 as multicast in the 
Intro. This would avoid the need to list MAP-E, MAP-T...
etc. throughout.

1.b)
s/Recently providers/Recently, providers/

1.c)
s/started to deploy IPv6 and consider how to transit to IPv6./
started deployment and transition to IPv6./

1.d)
"In particualr, the CE uses DHCPv6 options to discover the
   Border Relay (BR) and retrieve Softwire46 (S46) configurations."

This is one way that configuration can be done - there's also
a YANG model in development and DHCPv4o6 provisioning. It would be
more accurate to say:

"[RFC7598] defines DHCPv6 options for provisioning
CEs for unicast softwires."

1.e)
For the mutlicast section, all of the fields that are present
in OPTION_V6_PREFIX64 are described in full, but this is not
done for the unicast equivalents. It would make sense to be
uniform between the two, but if all of the options/sub-options
from RFC7598 get included, then it's going to get pretty long.

I think it would improve the consistency and readability
without brining in large amounts of duplication to remove
the text starting 'The following lists the multicast-related
information...' upto (and including) the Unicast Prefix64
description.

In it's place, a paragraph describing the relationship between
this document and RFC7598/8115 could be added, referencing the
relevant sections in those RFCs that the fields are defined.

1.f)
After the sentence "A DHCPv6 server function is
   assumed to be embedded in the BNG that allows it to locally handle 
   any DHCPv6 requests initiated by hosts." it would be
   worth adding that the term BNG is used througout the document
   to describe a device which functions as both the AAA client
   and DHCPv6 server. 

1.g)
s/MAP-E[RFC7597], MAP-T[RFC7599] and Lightweight 4over6[RFC7596]/
MAP-E [RFC7597], MAP-T [RFC7599] and Lightweight 4over6 [RFC7596]/

1.h)
s/options[RFC7598]/options [RFC7598]/

1.i)
Last paragraph: It would also be worth saying how the structure of the 
DHCP options and field namings are preserved so they can 
easily be mapped between DHCP and RADIUS.



3. Configuration Process with RADIUS
3.a)
s/CE with MAP/CE with softwire/

3.b)
s/how the RADIUS protocol and DHCPv6 co-operate/how the RADIUS and
DHCPv6 protocols co-operate/

3.c)
The figure is easier to follow if it is space out a bit more and 
clafifies the first step:

  CE BNG AAA Server
  |   |   |
  |---1.DHCPv6 Solicit--->|   |
  |(ORO with 

Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 1 of 2

[ianfarrer]

Hi,

I only saw comments on the first part of my review. Have you also seen the 
second part?

Please see below.

Thanks,
Ian


> 
>  
> 1.i)
> Last paragraph: It would also be worth saying how the structure of the 
> DHCP options and field namings are preserved so they can 
> easily be mapped between DHCP and RADIUS.
>  
> [fuyu] Do you mean to describe device implementation in more detail?
> 

[if - The contents of the sub-options defined in this draft have a 1:1 mapping 
into the fields of the various DHCP options
In RFC7598 and RFC8115. A table which gives the DHCP option and field name and 
matches this to the RADIUS
Attribute/option would make this easier to do.]

>  
> A MUST here is also strange. What if the AAA server doesn't have
> the requested configuration to supply to the client?
> [fuyu]  In the section 4.2 of RFC 2865, it also describes that “If all 
> Attribute values received in an
>   Access-Request are acceptable then the RADIUS implementation MUST
>   transmit a packet with the Code field set to 2 (Access-Accept).”
> So I think a MUST should be here.

[if - The RFC2865 text is saying the same as I am - 'if the attributes are 
acceptable’ i.e. if there is configuration
available and policy in place to supply it. 

.. The current draft text says:
"If the authentication request is approved by the AAA server, an
   Access-Accept message MUST be acknowledged with the corresponding
   Softwire46-Configuration Attribute…”

The authentication request being approved isn’t the same thing as having 
Softwire configuration available and
The policy to supply it to that customer. A suggested re-word:

3.  If the authentication request is approved by the AAA server, and suitable 
confguration is available, an Access-Accept message MUST be acknowledged with 
the corresponding
   Softwire46-Configuration Attribute or Softwire46-Multicast Attribute.

>  
>  
> 3.m)
> In the DHCPv6 Advertisement message, there needs to be the
> corresponding DHCPv6 option holding the correct information
> from the RADIUS message. This means that we need to map the 
> fields from the attributes to the options. A table showing
> how this mapping is done would be very useful.
>  
> [fuyu] Do you mean giving a table to describe DHCPv6 option and corresponding 
> attribute?
>  
> [i

[if - Yes. The table needs to show each DHCP option and the name of the fields 
in the option and map them
to the corresponding RADIUS attribute/sub-option.]

>  
> 3.s)
> The final 3 paragraphs deal with some error handling conditions. Perhaps
> a sub-section for these would make for a better structure?
> [fuyu] Ok, I will make a sub-section.
> 3.t)
> What happens if steps 1-4 complete, but the BNG never receives a
> request message from the client? In this case, the AAA has allocated
> resources, but they are not actually in use. Is there a way that
> the BNG can invalidate the request after a timeout, or is there
> another error handling mechanism that should be used?
>  
> 3.u)
> There's no text on what happens when the client send a DHCPv6 Release,
> Decline, or an associtated DHCPv6 lease expires (invalidating any
> options supplied with that lease).
>  
> [fuyu]  I think the key point in the document is to define RADIUS attribute. 
> Shall we need to define this
> DHCPv6 scenarios? I think it may be the text which RFC 7598 should include?

[if - I’ve just checked a few other DHCP/RADIUS RFCs and it seems that the 
convention is not to specify releasing attribute.
Comment withdrawn.]



___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard Track, closed by 27 June 2018

[ianfarrer]

Hi,

I’ve just posted v06 with the changes proposed below incorporated.

Thanks,
Ian

> On 29. Jun 2018, at 10:20,  
>  wrote:
> 
> Hi Ian,
>  
> Works for me. Thanks.
>  
> Cheers,
> Med
>  
> De : ianfar...@gmx.com [mailto:ianfar...@gmx.com] 
> Envoyé : vendredi 29 juin 2018 09:59
> À : BOUCADAIR Mohamed IMT/OLN; Sheng Jiang
> Cc : Softwires WG; softwire-cha...@ietf.org; Andy Wingo
> Objet : Re: [Softwires] WGLC for draft-ietf-softwire-yang-04 as Standard 
> Track, closed by 27 June 2018
>  
> Hi Sheng /Med,
>  
> @Sheng, Thanks for the review.
> @Med, Thanks for the quick update.
>  
> A couple of other things:
>  
> There’s an outstanding comment on model element descriptions given as “…”. 
> Proposed new text:
>  
> notification softwire-binding-instance-event description: "The ID of the 
> binding-instance that generated the notification.";
>  
> leaf-list modified-entry description "The ID of the the binding-table entry 
> that has been modified.";
>  
> --
> I just did a quick read through of -05. There are a few small language 
> cleanups that I would like to make:
>  
> Section 2.1
> s/Provides configuration and monitoring for softwire CE element/Provides 
> configuration and monitoring for the softwire CE element/
>  
> s/Provides configuration and monitoring for softwire BR element/Provides 
> configuration and monitoring for the softwire BR element/
>  
> Section 2.2
> s/be imported here, as needed/be imported, as needed/
>  
> ietf-softwire-ce:binding-entry/br-ipv6-addr
> description
> s/The IPv6 address for of the binding BR./The IPv6 address for the binding 
> BR./
>  
> ietf-softwire-br:br-instances/algorithm
> description
> s/Indicate that the instance supports the MAP-E and MAP-T functions./Indicate 
> that the instance supports the MAP-E and MAP-T functions./
>  
> If there’s no objection to the above changes, I’ll update and post later on 
> today.
>  
> Cheers,
> Ian
> 
> 
> On 27. Jun 2018, at 10:54, mohamed.boucad...@orange.com 
>  wrote:
>  
> Hi Sheng,
>  
> Many thanks for the careful review.
>  
> An updated version which integrates your comments is available 
> online:https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/?include_text=1
>  
>  
> See more inline.
>  
> Cheers,
> Med
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[ianfarrer]

Hi,

This version contains a few small language changes and cleanups.

Thanks,
Ian

> On 4. Nov 2018, at 15:00, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Softwires WG of the IETF.
> 
>Title   : YANG Modules for IPv4-in-IPv6 Address plus Port 
> (A+P) Softwires
>Authors : Yong Cui
>  Ian Farrer
>  Mohamed Boucadair
>  Qi Sun
>  Linhui Sun
>  Sladjana Zechlin
>  Rajiv Asati
>   Filename: draft-ietf-softwire-yang-12.txt
>   Pages   : 56
>   Date: 2018-11-04
> 
> Abstract:
>   This document defines YANG modules for the configuration and
>   operation of IPv4-in-IPv6 softwire Border Relays and Customer
>   Premises Equipment for the Lightweight 4over6, Mapping of Address and
>   Port with Encapsulation (MAP-E), and Mapping of Address and Port
>   using Translation (MAP-T) softwire mechanisms.  It also contains the
>   initial version of an IANA-maintained YANG module identifying tunnel
>   types.
> 
> Editorial Note (To be removed by RFC Editor)
> 
>   Please update these statements within this document with the RFC
>   number to be assigned to this document:
> 
>   o  "This version of this YANG module is part of RFC ;"
> 
>   o  "RFC : YANG Modules for IPv4-in-IPv6 Address plus Port
>  Softwires";
> 
>   o  "reference: RFC "
> 
>   Please update the "revision" date of the YANG modules.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-softwire-yang-12
> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-yang-12
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-yang-12
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Genart last call review of draft-ietf-softwire-yang-06

[ianfarrer]

Hi Roni,

I’ll add that for the next version.

Thanks,
Ian

> On 9. Oct 2018, at 09:02, Roni Even  wrote:
> 
> Reviewer: Roni Even
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-softwire-yang-??
> Reviewer: Roni Even
> Review Date: 2018-10-08
> IETF LC End Date: 2018-10-11
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is ready for publication as a standard track RFC with nits
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 1. In section 1 it says that the YANG data model can be used with netconf , I
> noticed that restconf is only mentioned in the security section as network
> management. why not add restconf to introduction?
> 
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] draft-ietf-softwire-yang-15 posted incorporating IESG eval. (and area review) comments

[ianfarrer]

Hi

We’ve just posted -15 of this draft incorporating the IESG evaluation 
DISCUSSes/comments and the Secdir/Genart review comments. Many thanks for those.

Thanks,
Ian

Below is the log of DISCUSS/Comments received during the review and the changes 
that have been incorporated to address them.


---

DISCUSS Points:

Alissa Cooper (Supported by Adam Roach, Ben Campbell, Warren Kumari and Alexey 
Melnikov)

The security considerations do not seem to follow the YANG security guidelines
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 
. They do not
list the specific writeable and readable subtrees/nodes and why they are
sensitive. The fact that all the writeable nodes could "negatively affect
network operations" seems trivially true for most writeable YANG module nodes.
In the case of these modules, there seem to be multiple different threats
relevant to different nodes, including exposure of data about individual
users/customers, potential for disruption of the operations of the BR or CE,
etc.

The Security Considerations section has been rewritten expressly describing
the threats associated to the relevant nodes.

--

Benjamin Kaduk (supported by Adam Roach, Benjamin Campbell and Alexey Melnikov)
Discuss 1

This document has 7 listed authors/editors. Since, per RFC 7322, documents
listing more than five authors are unusaul, and seven is greater than five,
let's talk about the author count.

The document follow’s Adam Roach’s suggestion (in support of Benjamin’s DISCUSS)
above, and now lists 2 editors and a Contributors section.

—

Benjamin Kaduk (Supported by Warren Kumari)
Discuss 2 

The binding-table-versioning container's "version" leaf is of type uint64
but the in-module description indicates that it is a timestamp. If it is
actually supposed to be a timestamp, then the units and zero time need to
be specified, but it seems more likely that this should just be described
as an abstract version number, if I understand the prose text about this
container correctly.

Description text changed to match the leaf’s type:
Version number for this binding table.

-

Comments:

Alissa Cooper
Comment 1
I think "external party" would make more sense than "abuse party.”

Sentence reworded (in both instances) to:
When a party who is the victim of abuse presents an external IP address/port,


—-

Benjamin Kaduk
Comment 1
Please expand CE on first usage.

The abstract gives the full name and the abbreviation is explained in the 
Introduction.

Comment 2
Section 4.1

It feels a little strange to put something as generic as
/if:interfaces/if:interface/if:statistics:sent-ipv4-packets in the
ietf-softwire-ce module. Are these counters likely to be useful for other
(non-softwire?) tunneling techniques?

The counters can be re-used bu other modules. No change is needed.

---

Comment 3
Section 5.2

o softwire-num-max: used to set the maximum number of softwire
binding rules that can be created on the lw4o6 element
simultaneously. This paramter must not be set to zero because
this is equivalent to disabling the BR instance.

This seems to leave it ambiguous whether a server should reject an attempt
to set it to zero, or accept it but diable the BR instance.

The text is clear.
range "1..max".

No change is needed.

---

Comment 4
Section 7

   leaf enable-hairpinning {
 type boolean;
 default "true";
 description
   "Enables/disables support for locally forwarding
(hairpinning) traffic between two CEs.";
 reference "Section 6.2 of RFC7596";

Is a global toggle sufficient or would there be cases where more
fine-grained control would be needed?

A+P is designed to reduce as much as possible the per-subscriber state at the 
network/BR. Requiring fine-grained control would require some extra state to be 
maintained, which is not desired. Having the general parameter is sufficient.

---

Comment 5
Section 8

container algo-versioning {
[...]
leaf date {

   type yang:date-and-time;
   description
 "Timestamp when the algorithm instance was activated.

  An algorithm instance may be provided with mapping
  rules that may change in time (for example, increase
  the size of the port set). When an abuse party
  presents an external IP address/port, the version
  of the algorithm is important because depending on
  the version, a distinct customer may be identified.

nit: "abuse party" is probably not a term that everyone is familiar with.
(similarly in br-instances)

Sentence reworded to:
When a party who is the victim of abuse presents an external IP address/port,

---

Comment 6
Section 9
Is there any possibility of a situation where the
invalid-/added/modified-entry notifications cause a substantial amount of
notification traffic (i.e., a DoS level of traffic)?

Added some text among those lines:

This is in theory possible if the BR 

Re: [Softwires] Secdir last call review of draft-ietf-softwire-yang-14

[ianfarrer]

Hi Phillip,

Thank you for your review and comment.

We’ve re-written the Security Guidelines section following the guidance here: 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 
 and Section 
3.7.1 of RFC8407. The proposed text is below.

However, your comment is not really covered by those guidelines, assuming that 
it is applicable to YANG processing generally, rather than the modules in this 
draft specifically.  The focus of the security section is more related to 
configuration and state nodes which the module exposes and threats associated 
with them rather than how those nodes are accessed.

In existing YANG documents the closest I’ve found is from RFC6020 (and RFC7950) 
Sec. Considerations:

"YANG parsers need to be robust with respect to malformed documents.
   Reading malformed documents from unknown or untrusted sources could
   result in an attacker gaining the privileges of the user running the
   YANG parser.  In an extreme situation, the entire machine could be
   compromised."

Do you think that this text addresses your comment? If so, I will include a 
pointer to it.

Thanks,
Ian


9.  Security Considerations

   The YANG modules defined in this document is designed to be accessed
   via network management protocols such as NETCONF [RFC6241] or
   RESTCONF [RFC8040].  The lowest NETCONF layer is the secure transport
   layer, and the mandatory-to-implement secure transport is Secure
   Shell (SSH) [RFC6242].  The lowest RESTCONF layer is HTTPS, and the
   mandatory-to-implement secure transport is TLS [RFC8446].

   The NETCONF access control model [RFC8341] provides the means to
   restrict access for particular NETCONF or RESTCONF users to a
   preconfigured subset of all available NETCONF or RESTCONF protocol
   operations and content.

   All data nodes defined in the YANG modules which can be created,
   modified, and deleted (i.e., config true, which is the default) are
   considered sensitive.  Write operations (e.g., edit-config) applied
   to these data nodes without proper protection can negatively affect
   network operations.  An attacker who is able to access the BR can
   undertake various attacks, such as:

   o  Setting the value of 'br-ipv6-addr' on the CE to point to an
  illegitimate BR so that it can intercept all the traffic sent by a
  CE.  Illegitimately intercepting users' traffic is an attack with
  severe implications on privacy.

   o  Setting the MTU to a low value, which may increase the number of
  fragments ('softwire-payload-mtu').

   o  Disabling hairpinning (i.e., setting 'enable-hairpinning' to
  'false') to prevent communications between CEs.

   o  Setting 'softwire-num-max' to an arbitrary high value, which may
  be exploited by a misbehaving user to perform a DoS on the binding
  BR by mounting a massive number of softwires.

   o  Setting 'icmpv4-rate' or 'icmpv6-rate' to a low value, which may
  lead to the deactivation of ICMP messages handling.

   o  Accessing to privacy data maintained by the BR (e.g., the binding
  table or the algorithm configuration).  Such data can be misused
  to track the activity of a host.

   o  Instructing the BR to install entries which in turn will induce a
  DDoS attack by means of the notifications generated by the BR.
  This DDoS can be softened by defining a notification interval, but
  given that this interval parameter can be disabled or set to a low
  value by the misbehaving entity, the same problem will be
  observed.

   Security considerations related to lw4o6, MAP-T, and MAP-E are
   discussed in [RFC7596], [RFC7597], and [RFC7599] respectively.

> On 7. Jan 2019, at 17:22, Phillip Hallam-Baker  wrote:
> 
> Reviewer: Phillip Hallam-Baker
> Review result: Has Nits
> 
> The document describes a schema and has appropriately identified the 
> read/write
> security concerns arising from it.
> 
> One issue that I thing could be usefully spelled out is that the use of
> automated tools to decode structures of this type is not merely a programming
> convenience. Attempts to parse length delimited objects nested in length
> delimited structures using handwritten code is error prone and has led to
> introduction of numerous buffer overrun vulnerabilities.
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] WGLC for draft-ietf-softwire-iftunnel-01

[ianfarrer]

Hi Yong,

Further to my previous email.

During the review of draft-ietf-softwire-yang, there is a comment about 
following the published format for the Security Considerations section of a 
document containing a YANG module. I wasn’t previously aware of this:

https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 


As this comment will also be applicable to draft-ietf-softwire-iftunnel, I 
think we need to rewrite the Security Considerations section accordingly.

Thanks,
Ian

> On 8. Jan 2019, at 17:48, ianfar...@gmx.com wrote:
> 
> HI Yong,
> 
> Sorry for the late response. I’m still catching up after the holidays…
> 
> As a co-author, I support this document progressing. As you mention below, 
> separating out the iftunnels module from draft-ietf-softwire-yang into a new 
> draft was requested during the IANA review.  meaning that 
> draft-ietf-softwire-yang (currently with the IESG) now has a normative 
> reference to this draft.
> 
> Regarding the draft itself, the iftunnel module itself has already been 
> through the final WGLC for draft-ietf-softwire-yang. As it models the IANA 
> tunnelType Definitions registry 
> (https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6 
> ),
>  we’ve tried to keep the format in line with other, similar documents with 
> YANG modules for other IANA registries (e.g. RFC7224).
> 
> Thanks,
> Ian
> 
>> On 19. Dec 2018, at 08:26, Yong Cui > > wrote:
>> 
>> Dear all,
>> 
>> There were the following progress on Softwire YANG and related work during 
>> the past couple of months:
>>  • draft-ietf-softwire-yang completed WGLC
>>  • During expert review, a YANG module for the iana-iftunnel registry 
>> was requested as the softwire module needs to reference it.
>>  • draft-ietf-softwire-yang was updated to include this module and Sheng 
>> ran a WGLC on the new content. This passed without comment.
>>  • During IANA review, it was requested that the iana-iftunnel YANG 
>> module was put into a separate document.
>>  • draft-ietf-softwire-yang was updated, removing the iana-iftunnel YANG 
>> module, and draft-ietf-softwire-iftunnel was published containing just the 
>> module (it was posted as a WG doc as the content etc. is already under the 
>> scope of draft-ietf-softwire-yang)
>> 
>> So now, we’d like to issue a WGLC for draft-ietf-softwire-iftunnel-01. 
>> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/ 
>> 
>> 
>> Considering the coming Christmas and New Year, I would extend the WGLC to 3 
>> weeks, i.e. Dec. 19, 2018 - Jan. 9, 2019. Please send your comments to our 
>> softwire mailing list, including your support or concerns.
>> 
>> 
>> Merry Christmas and Happy New Year!
>> 
>> Yong & Ian
>> 
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Suresh Krishnan's No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

[ianfarrer]

Hi Suresh,

Please see inline below.

Thanks,
Ian

> On 10. Jan 2019, at 15:05, Suresh Krishnan  wrote:
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-softwire-yang-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I would have thought putting in a prioritization mechanism (like RFC8026 does)
> for ordering the different mechanisms would have been useful in this YANG
> module in order to configure the CE. Was this something that was considered?
> 
> 

[if - The intention of RFC8026 was to give greater control when you have 
multiple softwire
mechanisms in use (e.g. during migration) and CE devices with unknown 
capabilities (different
age devices, user supplied etc). It gives a way of a CE side implementation of 
a stateless (in the
DHCP server) prioritisation policy (throw enough config and the best available 
one sticks)

Due to Netconf/YANGs much greater interaction - capabilities exchanges, 
features, deviations etc., it’s
easier to configure specific devices with only the config they are capable of 
and you want them to run, so
you don’t get the case where the host has multiple configurations to choose 
from.
]

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Genart last call review of draft-ietf-softwire-yang-06

[ianfarrer]

Hi Roni,

My apologies for the oversight. I’ve just posted -14 which includes the 
RESTCONF reference in the Introduction.

Thanks,
Ian

> On 9. Oct 2018, at 09:02, Roni Even  wrote:
> 
> Reviewer: Roni Even
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-softwire-yang-??
> Reviewer: Roni Even
> Review Date: 2018-10-08
> IETF LC End Date: 2018-10-11
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is ready for publication as a standard track RFC with nits
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 1. In section 1 it says that the YANG data model can be used with netconf , I
> noticed that restconf is only mentioned in the security section as network
> management. why not add restconf to introduction?
> 
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Mirja Kühlewind's No Objection on draft-ietf-softwire-yang-14: (with COMMENT)

[ianfarrer]

Hi Mirja,

Thanks for your comments. Please see inline below.

Regards,
Ian

> On 7. Jan 2019, at 18:06, Mirja Kühlewind  wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-softwire-yang-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Some minor comments:
> 
> 1) Sec 4.2:
> "softwire-path-mru: optionally used to set the maximum IPv6
>  softwire packet size that can be received, including the
>  encapsulation/translation overhead.  Needed if the softwire
>  implementation is unable to correctly calculate the correct IPv4
>  Maximum Receive Unit (MRU) size automatically [RFC4213]."
> I guess this should both be IPv6…?

[if - This parameter is provided to address the possible fragmentation
problems described in RFC4213 section 3.2, where the sender is sending
encapsulated packets based on the IPv6 MTU resulting in the receiver
getting IPv4 payloads larger than they can process, or requiring the IPv4
to be fragmented, so the second IPv4 is correct.


Would the following wording for the second sentence make this more clear?:

Needed if the softwire implementation is unable to correctly
calculate the correct IPv4 payload Maximum Receive Unit (MRU)
size automatically (see Section 3.2 of [RFC4213]).
]


> 
> 2) Why does the description of "rcvd-ipv4-bytes" say
> "IPv4 traffic received for processing, in bytes"..?
> Does the "for processing" have any special meaning or why is it only phrased
> like this for that one entry?

[if - No special meaning is intended. Will reword with:

IPv4 traffic received, in bytes.
]

> 
> 3) Also the description for "sent-ipv4-bytes" and "sent-ipv4-packets" could be
> unified.

[if - Will reword the rcvd-ipv4-packets description (also aligned with the 
rcvd-ipv6-packets
description:

Number of IPv4 packets received.
]
> 
> 

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] WGLC for draft-ietf-softwire-iftunnel-01

[ianfarrer]

HI Yong,

Sorry for the late response. I’m still catching up after the holidays…

As a co-author, I support this document progressing. As you mention below, 
separating out the iftunnels module from draft-ietf-softwire-yang into a new 
draft was requested during the IANA review.  meaning that 
draft-ietf-softwire-yang (currently with the IESG) now has a normative 
reference to this draft.

Regarding the draft itself, the iftunnel module itself has already been through 
the final WGLC for draft-ietf-softwire-yang. As it models the IANA tunnelType 
Definitions registry 
(https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6 
),
 we’ve tried to keep the format in line with other, similar documents with YANG 
modules for other IANA registries (e.g. RFC7224).

Thanks,
Ian

> On 19. Dec 2018, at 08:26, Yong Cui  wrote:
> 
> Dear all,
> 
> There were the following progress on Softwire YANG and related work during 
> the past couple of months:
>   • draft-ietf-softwire-yang completed WGLC
>   • During expert review, a YANG module for the iana-iftunnel registry 
> was requested as the softwire module needs to reference it.
>   • draft-ietf-softwire-yang was updated to include this module and Sheng 
> ran a WGLC on the new content. This passed without comment.
>   • During IANA review, it was requested that the iana-iftunnel YANG 
> module was put into a separate document.
>   • draft-ietf-softwire-yang was updated, removing the iana-iftunnel YANG 
> module, and draft-ietf-softwire-iftunnel was published containing just the 
> module (it was posted as a WG doc as the content etc. is already under the 
> scope of draft-ietf-softwire-yang)
> 
> So now, we’d like to issue a WGLC for draft-ietf-softwire-iftunnel-01. 
> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> 
> Considering the coming Christmas and New Year, I would extend the WGLC to 3 
> weeks, i.e. Dec. 19, 2018 - Jan. 9, 2019. Please send your comments to our 
> softwire mailing list, including your support or concerns.
> 
> 
> Merry Christmas and Happy New Year!
> 
> Yong & Ian
> 

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-16.txt

[ianfarrer]

Hi Yu,

Please see inline below.

Thanks,
Ian

> On 17. Aug 2018, at 11:48, Yu Fu  wrote:
> 
> Hi Ian
> 
>  
> 
> Thanks for your thorough  comments. Please see my reply below:
> 
>  
> 
> BR
> 
> Yu 
> 
>  
> 
> Hi Yu,
> 
> Thanks for the update. I think the changes that you have made have improved 
> the document significantly, but there’s still a few things that need to be 
> addressed. Please see below.
> 
> Also, Jordi asked a question about this draft, which I don’t think has been 
> replied to:
> https://mailarchive.ietf.org/arch/msg/softwires/_7ocUxBwy9i2UqNj2tzqri9p0Gw 
> 
> [fuyu]: From my side. I am happy to support 464XLAT, but I have made  a 
> tremendous effort to consistent with the different attribute format and 
> writing style after adding the multicast use case. 
> I am not sure that I can do the same work after adding this new function.  
> Could the Jordi help me to do that work? 

[if -  I’ve emailed the authors separately on this]

>  
> 
> 
> Thanks,
> Ian
> 
> New comments on -16:
> 
> Throughout - the use of 'Sub TLV' and 'Sub-TLV' is not consistent.
> Sub-TLV seems to be the convention in other RFCs (e.g. RFC6929).
> 
> [fuyu] I will check out all through the text for consistent.
> 
> 
> 
> Introduction.
> 
> s/At the Section 4.9/In Section 4.9/
> 
> As the softwire prioritisation funciton of RFC8026 is also
> included, there should be a short paragraph (a cut down version of
> sec 4, para 3) stating that this function is included.
> 
> [fuyu]: Do you think add a sentence as “A new Softwire46-Priority Attribute 
> contains RADIUS information corresponding to OPTION_S46_PRIORITY defined in 
> [RFC8026] is defined in Section 4.8.” will be Ok?
> 
[if - OK]

> 
> 
> 1.i)
> Last paragraph: It would also be worth saying how the structure of the
> DHCP options and field namings are preserved so they can
> easily be mapped between DHCP and RADIUS.
> 
> [if - I can't find any changes in the text for this, or any repsonse
> to the comment.]
> 
> [fuyu]: Do you think a table as following will be help?
> 
> 
>   
> +---+-+
> 
>   |  DHCPv6 Option   | RADIUS Attribute/Sub TLV |
> 
>   
> +---+---+
> 
>   | OPTION_S46_RULE| S46-Rule Sub TLV   |  
> 
>   
> +-+-+
> 
>   |   OPTION_S46_BR   |S46-BR Sub TLV   |  
> 
>   
> +---++ 
> 
>   |  ……|……
> |  
> 
>   +--+--+ 
> 
>
> 
[if - Yes, that’s what I had in mind]
> 
> 
> 
> 
> 3.c)
> The figure is easier to follow if it is space out a bit more and
> clafifies the first step:
> 
>  CE BNG AAA Server
>  |   |   |
>  |---1.DHCPv6 Solicit--->|   |
>  |(ORO with unicast and/or m'cast|   |
>  |container option code(s))  |   |
>  |   |   |
>  |   |---2.Access-Request--->|
>  |   | (S46-Configuration attribute  |
>  |   |and/or S46-Multicast attribute)|
>  |   |   |
>  |   |<--3.Access-Accept-|
>  |   | (S46-Configuration attribute  |
>  |   |and/or S46-Multicast attribute)|
>  |   |   |
>  |<4.DHCPv6 Advertisement|   |
>  | (container option(s)) |   |
>  |   |   |
>  |---5.DHCPv6  Request-->|   |
>  | (container Option(s)) |   |
>  |   |   |
>  |<6.DHCPv6 Reply|   |
>  | (container option(s)) |   |
>  |   |   |
>   DHCPv6 RADIUS
> 
> [if - Old diagram is still present, please use the above figure.]
> [fuyu]: Ok, I have updated it.
> 
> 3.f)
> Replace:
> For the multicast case, OPTION_V6_PREFIX64 should be included for the 
> delivery of multicast
>   services 

Re: [Softwires] Regarding the Next Hop Network Address coding for IPv4 VPN over IPv6 Core in RFC5549

[ianfarrer]

Hi,

My reading of Section 3 of RFC5549 is that the v6 next-hop is encoded as an 
IPv6 address:
 
   The BGP speaker receiving the advertisement MUST use the Length of
   Next Hop Address field to determine which network-layer protocol the
   next hop address belongs to.  When the Length of Next Hop Address
   field is equal to 16 or 32, the next hop address is of type IPv6.

It’s also worth noting that RFC4659 Section 2 states:
 
A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
   "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.

So, not 16 or 32 bytes.

Thanks,
Ian


> On 22. Jun 2019, at 09:59, Zhuangshunwan  wrote:
> 
> Dear authors and WGs,
>  
> RFC5549 Section 6.2 says: 
>  
> . 6.2.  IPv4 VPN over IPv6 Core
> . 
> .The extensions defined in this document may be used for support of
> .IPV4 VPNs over an IPv6 backbone.  In this application, PE routers
> .would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6
> .Next Hop.
> . 
> .The MP_REACH_NLRI is encoded with:
> . 
> .o  AFI = 1
> . 
> .o  SAFI = 128
> . 
> .o  Length of Next Hop Network Address = 16 (or 32)
> . 
> .o  Network Address of Next Hop = IPv6 address of Next Hop
> . 
> .o  NLRI = IPv4-VPN routes
>  
>  
> Regarding IPv4-VPN routes, RFC4634 Section 4.3.2 says:
>  
> . 4.3.2.  Route Distribution Among PEs by BGP
> [snip]
> .When a PE router distributes a VPN-IPv4 route via BGP, it uses its
> .own address as the "BGP next hop".  This address is encoded as a
> .VPN-IPv4 address with an RD of 0.  ([BGP-MP] requires that the next
> .hop address be in the same address family as the Network Layer
> .Reachability Information (NLRI).)  It also assigns and distributes an
> .MPLS label.  (Essentially, PE routers distribute not VPN-IPv4 routes,
> .but Labeled VPN-IPv4 routes.  Cf. [MPLS-BGP].)  When the PE processes
> .a received packet that has this label at the top of the stack, the PE
> .will pop the stack, and process the packet appropriately.
> [snip]
>  
>  
> Question:
> RFC5549 defines "IPv4 VPN over IPv6 Core", When a PE router distributes a 
> VPN-IPv4 route with an IPv6 Next-Hop via BGP, should the IPv6 Next-Hop be 
> encoded as an VPN-IPv6 address with an RD of 0 ? 
>  
>  
> Thanks,
> Shunwan
> ___
> Softwires mailing list
> Softwires@ietf.org 
> https://www.ietf.org/mailman/listinfo/softwires 
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

[ianfarrer]

Hi Éric,

My reading of the current RFC6333 text is that it is trying to highlight the 
importance of not fragmenting the IPv4 packet before encapsulation as this will 
break things. This, combined with ‘… after the encapsulation of the IPv6 
packet.’ which should certainly be ‘… of the IPv4 packet.’ Is where the 
confusion is from.

So, as a minimum, the errata is correct regarding the encapsulated IP version.

Beyond that, I don’t find the remaining text to conflict with RFC2743 section 
7.2. The text is only covering how to deal with packets that you will 
encapsulate and forward (DF=0) - case (b) in the RFC2473 text. Case (a) - DF=1 
for received packet, so drop and send ICMP error isn’t discussed as these 
packets will not be encapsulated and need to be fragmented.

I do agree that this is open to misreading. How about the following wording to 
preserve (what I think is) the authors intention:

>However, as not all service providers will be able to increase their
>link MTU, the B4 element MUST perform fragmentation and reassembly if
>the outgoing link MTU cannot accommodate the extra IPv6 header.  The
>original IPv4 packet is not oversized.  The packet is oversized after
>the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
>fragmented.  For packets forwarded by the B4 element, fragmentation
  MUST happen after the encapsulation of the IPv4 packet.  Reassembly
MUST happen before the decapsulation of the IPv4 packet.  A detailed
procedure has been specified in [RFC2473]
> 
>Section 7.2.



From Mikael’s comment:
"RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or 
drop+send ICMP error."

I can’t find anything in the Section 7.2 text that would result in inner 
fragmentation.

Thanks,
Ian


> On 10. May 2021, at 15:36, Eric Vyncke (evyncke) 
>  wrote:
> 
> Dear ex-softwires WG, dear int-area WG,
>  
> Mikael Abrahamsson filed an erratum https://www.rfc-editor.org/errata/eid5847 
>  in August 2019 (after the 
> softwires WG closure) and, as the past responsible AD for softwires, I would 
> like to fix this erratum but as Mikael I have no idea about the correction.
>  
> My own take is that the normative text in RFC 6333 indeed violates RFC 2473 
> for when the IPv4 DF is set... RFC 2473 appears to me as sensible and I would 
> prefer to keep this behavior, i.e., see my suggestion below.
>  
> Than you in advance for your comments and suggestions,
>  
> Regards
>  
> -éric
>  
>  
> -- Existing text in RFC 6333 –
> Section 5.3 says:
> 
>However, as not all service providers will be able to increase their
>link MTU, the B4 element MUST perform fragmentation and reassembly if
>the outgoing link MTU cannot accommodate the extra IPv6 header.  The
>original IPv4 packet is not oversized.  The packet is oversized after
>the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
>fragmented.  Fragmentation MUST happen after the encapsulation of the
>IPv6 packet.  Reassembly MUST happen before the decapsulation of the
>IPv4 packet.  A detailed procedure has been specified in [RFC2473]
>Section 7.2.
>  
>  
> -- Comment by erratum submitter –
> I do not have a corrected text. The above text doesn't say what RFC2473 
> section 7.2 says, so... what should it be? RFC2473 7.2 says to use the DF bit 
> and decide whether to inner fragment or drop+send ICMP error. The above text 
> seems to make normative statements that counter at least the DF=1 case in 
> RFC2473 7.2. Also the text above says "Fragmentation MUST happen after the 
> encapsulation of the IPv6 packet.". The IPv6 packet isn't encapsulated, so 
> that sentence should be changed?
>  
> -- Section 7.2 of RFC 2473 ---
>When an IPv4 original packet enters a tunnel, if the original packet
>size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
>entry-point and the tunnel exit-point, minus the size of the tunnel
>header(s)), it is handled as follows:
>  
> (a)  if in the original IPv4 packet header the Don't Fragment  -
>  DF - bit flag is SET, the entry-point node discards the
>  packet and returns an ICMP message.  The ICMP message has
>  the type = "unreachable", the code = "packet too big", and
>  the recommended MTU size field set to the size of the
>  tunnel MTU - see sections 6.7 
>  and 8.3 
> .
>  
> (b)  if in the original packet header the Don't Fragment - DF  -
>  bit flag is CLEAR, the tunnel entry-point node encapsulates
>  the original packet, and subsequently fragments the
>  resulting IPv6 tunnel packet into IPv6 fragments that do
>  not exceed the Path MTU to the tunnel exit-point.
>  
>  
> -- Suggested new text by Éric Vyncke –

Re: [Softwires] DS-Lite address

[ianfarrer]

Hi,

Your email got held up the the spam filters. In order to post directly to the 
email list, you need to register at: 
https://www.ietf.org/mailman/listinfo/softwires

To your question, I’m not familiar with the specifics of your operator’s 
network or service, but hopefully the following information will help:

The 192.0.0.4 address is taken from the address range 192.0.0.0./29 which is a 
"Special Purpose Address" 
(https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
 
).
 This is a “Globally Reachable False” IPv4 address range (i.e. it is not 
permitted to appear on the public IPv4 Internet, so you should be able to 
successfully traceroute to it).

192.0.0.0/29 is defined as the ‘IPv4 Service Continuity Prefix’ (RFC7335). and 
is used for configuring an v4 address locally on a device which is actually 
only has an IPv6 connection to the Internet (and no public IPv4 address). This 
IPv4 address is needed by the IPv4/IPv6 transition technology (in your case, I 
would guess that 464XLAT is the IPv4/IPv6 transition technology being used 
here).

With 464XLAT, IPv4 traffic on the device with the source address of 192.0.0.4 
(in your case) is translated to a global (public) IPv6 address so it can be 
sent across the operator’s IPv6 only network. In the operator’s network, there 
is another device which performs the translation from IPv6 to a public IPv4 
address which can be routed on the IPv4 Internet (this might be the 
‘randomised’ IPv4 address you are seeing). It’s worth noting that the same 
192.0.0.4 address will appear on all devices using this service from this 
operator, as it never leaves the device.

Regarding setup for different cellular service providers etc., normally the 
relevant configuration is pushed to a device by the operator, so manual 
configuration for an APN should not be necessary, but you’d need to talk to 
your provider about that.

Hope this helps.

Ian


> On 12. Mar 2022, at 15:54, nicholas  
> wrote:
> 
> Hello,
> 
> I'm technologically retarded, so please excuse my naivety. My question is why 
> does my phone SIM card have a static ip address of 192.0.0.4?
> Incidentally, when I login to a private wifi network, and disconnect my 
> cellular data, a traceroute using the 192.0.0.4 address (which I consider 
> null since I'm no longer using the cellular distributor of that address) 
> still shows 4 to 5 other devices, routers, networks or whatever, on the route 
> to my phone? For a centuryLink network it usually contains Qwest legacy IP's, 
> while comcast uses comcast IP's. Similarly, when my cell phone plan expires 
> (I currently use a trakphone Walmart simple family that is powered by the 
> T-mobile network) my phone status still shows that I have an ip address of 
> 192.0.0.4 and the "4g" data symbol is still visible in the upper corner of my 
> phone with input/output arrows blinking. However, the use of my phone, text 
> and  internet are restricted. Yet, my SIM status shows that I my phone is 
> "connected" and service state is "active"? Another thing that I do not 
> understand and  which really messes with my emotions, is when I search for a 
> national carrier, whet
> her or not known businesses like T-mobile, Verizon, Sprint, etc., show up in 
> my network search, my phone will not accept any of them and instead will 
> automatically connect to the cellular carrier named "HOME". Incidentally, I 
> don't like the look of my default APN, which is also tied to my static 
> 192.0.0.4 IP, as when I fill in different APN settings that I find online my 
> ip address will then become randomized
> 
> Thank you so much for your time.
> Any information (preferably in layman's terms) would be greatly appreciated!
> Cheers,
> Nick James
> 
> ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires