Re: [Softwires] WG Review: Recharter of Softwires (softwire)

[Satoru Matsushima <[e-mail]>]

Hi Peng,


2011/4/20 Peng Wu <[e-mail]>:
> Hi Satoru,
>
> About the item DS-Lite with no NAT or NAT on the B4, it's DS-lite without CGN on the AFTR.
> Generally B4 will get public IPv4 address allocated from the ISP and use it for IPv4 access. The AFTR will only need to maintain IPv6-IPv4 address mapping without port information.
> Doing this the addressing and routing between IPv6 and IPv4 are still independent. It's a protocol extenstion to DS-lite, and it can work along with DS-lite.

So you mean that your 4over6 document is a B4NAT document, isn't it?
But I don't find any B4NAT definition in your document though.
On the other hand, I understand that you propose another 4over6
deployment model, which you don't need to use ds-lite terminology. You
already define 4over6 initiator and concentrator, etc., So I think
that using "B4NAT" makes confusion.

>
> We've already present it in last three IETF meetings. See http://tools.ietf.org/html/draft-cui-softwire-host-4over6-04. The general idea is out there, and the only confusion is that the mechanism name hasn't matched yet.
> We'll come up with a new version with evolvement before next IETF for WG adoption.

I'm confused because current ds-lite document clearly define as follow
in section 4.2:

  "A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
   interface and a B4 interface, as the NAT function will be performed
   by the AFTR in the service provider's network.  That will avoid
   accidentally operating in a double NAT environment."

And section 5.1 describes as follow:

  "5.  B4 element
   5.1.  Definition

   The B4 element is a function implemented on a dual-stack capable
   node, either a directly connected device or a CPE, that creates a
   tunnel to an AFTR."

These mean that B4 is equal to CPE, so that B4 cannot has NAT function.
Is that correct?

Best regards,
--satoru

>
>
> ------------------
> Peng Wu
> PhD candidate
> Department of Computer Science & Technology
> Tsinghua University, Beijing, China
>
> -------------------------------------------------------------
> From:Satoru Matsushima
> Date:2011-04-20 14:33:47
> To:iesg
> CC:softwires; cuiyong
> Subject:Re: [Softwires] WG Review: Recharter of Softwires (softwire)
>
>>Hello,
>>
>>I have some comments for the recharter text.
>>
>>>  4. Developments for stateless legacy IPv4 carried over IPv6
>>
>>What does "legacy" mean?
>>I think that no adjective needs to what IPv4 is.
>>
>>>     - develop a solution motivation document to be published as an
>>>       RFC
>>>     - develop a protocol specification response to the solution
>>> motivation
>>>       document; this work item will not be taken through WG last call
>>>       until the solution motivation document has been published
>>
>>It is unclear for the milestone to indicate this item. I think that
>>the milestone should explicitly include the schedule for both solution
>>motivation document and protocol specification for stateless solution.
>>Here's one proposal:
>>
>>Jul 2011 Submit solution motivation document for Stateless IPv4 over
>>IPv6 for Informational
>>Jul 2011 Adopt Stateless IPv4 over IPv6 protocol specification as WG document
>>Nov 2011 Submit Stateless IPv4 over IPv6 protocol specification for
>>Proposed Standard
>>
>>> Sep 2011 Submit B4NAT for Informational
>>
>>I don't understand what B4NAT is. Is there any discussion about B4NAT
>>in softwires WG so far?
>>If not, it hasn't appropriate yet that the charter includes B4NAT as an item.
>>
>>
>>Best regards,
>>--satoru
>>
>>
>>2011/4/20 IESG Secretary <[e-mail]>:
>>> A modified charter has been submitted for the Softwires (softwire) working
>>> group in the Internet Area of the IETF.  The IESG has not made any
>>> determination as yet.  The modified charter is provided below for
>>> informational purposes only.  Please send your comments to the IESG
>>> mailing list ([e-mail]) by Tuesday, April 26, 2011.
>>>
>>>
>>> Softwires (softwire)
>>> **DRAFT 2011-04-14** (v03)
>>> --------------------
>>> Current Status: Active
>>>
>>>  Chairs:
>>>     Alain Durand <[e-mail]>
>>>     Yong Cui <[e-mail]>
>>>
>>>  Internet Area Directors:
>>>     Ralph Droms <[e-mail]>
>>>     Jari Arkko <[e-mail]>
>>>
>>>  Internet Area Advisor:
>>>     Ralph Droms <[e-mail]>
>>>
>>>  Mailing Lists:
>>>     General Discussion: [e-mail]
>>>     To Subscribe:       [e-mail]
>>>     Archive:
>>> http://www.ietf.org/mail-archive/web/softwires/current/maillist.html
>>>
>>> Description of Working Group:
>>>
>>>  The Softwires Working Group is specifying the standardization of
>>>  discovery, control and encapsulation methods for connecting IPv4
>>>  networks across IPv6 networks and IPv6 networks across IPv4 networks
>>>  in a way that will encourage multiple, inter-operable
>>>  implementations.
>>>
>>>  For various reasons, native IPv4 and/or IPv6 transport may not be
>>>  available in all cases, and there is a need to tunnel IPv4 in IPv6
>>>  or IPv6 in IPv4 to cross a part of the network which is not IPv4 or
>>>  IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies
>>>  two distinct topological scenarios that the WG will provide
>>>  solutions for: "Hubs and Spokes" and "Mesh." In the former case,
>>>  hosts or "stub" networks are attached via individual,
>>>  point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a
>>>  centralized Softwire Concentrator. In the latter case (Mesh),
>>>  network islands of one Address Family (IPv4 or IPv6) are connected
>>>  over a network of another Address Family via point to multi-point
>>>  softwires among Address family Border Routers (AFBRs).
>>>
>>>  The WG will reuse existing technologies as much as possible and only
>>>  when necessary, create additional protocol building blocks.
>>>
>>>  For generality, all base Softwires encapsulation mechanisms should
>>>  support all combinations of IP versions over one other (IPv4 over
>>>  IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6
>>>  translation mechanisms (NAT-PT), new addressing schemes, and block
>>>  address assignments are out of scope. DHCP options developed in this
>>>  working group will be reviewed jointly with the DHC WG.  RADIUS
>>>  attributes developed in this working group will be reviewed jointly
>>>  with the RADEXT WG.  The MIB Doctors directorate will be asked to
>>>  review any MIB modules developed in the SOFTWIRE working group.  BGP
>>>  and other routing and signaling protocols developed in this group
>>>  will be reviewed jointly with the proper working groups and other
>>>  workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG,
>>>  etc).
>>>
>>>  The specific work areas for this working group are:
>>>
>>>  1. Developments for Mesh softwires topology; the Mesh topology work
>>>     will be reviewed in the l3vpn and idr WGs
>>>     - multicast
>>>     - MIB module
>>>
>>>  2. Developments for 6rd:
>>>     - multicast
>>>     - operational specification
>>>     - RADIUS option for 6rd server
>>>     - MIB module
>>>
>>>  3. Developments for Dual-Stack Lite (DS-Lite):
>>>     - multicast
>>>     - operational specification
>>>     - RADIUS option for AFTR
>>>     - proxy extensions; GI-DS-Lite; DS-Lite with no NAT or NAT on the
>>>       B4 element
>>>     - MIB module
>>>
>>>  4. Developments for stateless legacy IPv4 carried over IPv6
>>>     - develop a solution motivation document to be published as an
>>>       RFC
>>>     - develop a protocol specification response to the solution
>>> motivation
>>>       document; this work item will not be taken through WG last call
>>>       until the solution motivation document has been published
>>>
>>>  5. Finalize discovery and configuration mechanisms for a gateway to
>>>     use DS-Lite or 6rd; these discovery and configuration mechanisms
>>>     must take into a account other operating environments such as
>>>     dual-stack and tunneling mechanisms not defined by the softwire
>>>     WG.  Development of new mechanisms will involve the dhc and/or
>>>     v6ops WGs as appropriate
>>>
>>> Other work items would require WG approval and rechartering.
>>>
>>> Goals and Milestones:
>>> Apr 2011 Submit DS-lite RADIUS option for Proposed Standard
>>> Apr 2011 Adopt DS-lite operational document as WG document
>>> Jul 2011 Submit 6rd RADIUS option for Proposed Standard
>>> Jul 2011 Submit GI DS-lite for Proposed Standard
>>> Jul 2011 Adopt B4NAT as WG document
>>> Aug 2011 Adopt 6rd operational document as WG document
>>> Aug 2011 Adopt Multicast extensions document as WG document
>>> Aug 2011 Submit DS-lite operational document for Informational
>>> Sep 2011 Submit B4NAT for Informational
>>> Nov 2011 Submit Multicast extensions document for Informational
>>> Nov 2011 Submit 6rd operational document for Informational
>>> Nov 2011 Adopt 6rd MIB module as WG document
>>> Nov 2011 Adopt DS-lite MIB module as WG document
>>> Nov 2011 Adopt Mesh topology MIB module as WG document
>>> Nov 2012 Submit 6rd MIB module for Proposed Standard
>>> Nov 2012 Submit DS-lite MIB module for Proposed Standard
>>> Nov 2012 Submit Mesh topology MIB module for Proposed Standard
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>_______________________________________________
>>Softwires mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/softwires
>