Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

[Qi Sun <[e-mail]>]

Hi Reinado,

IMHO, both MAP(Mapping of Address and PORT ) and lw4over6 DO NOT
design to deal with full Ipv4 address case originally. In many
senarios,  users(like campanies, governments, ICPs and so on ) JUST
want full addresses instead of  shared addresses. It is more
reasonable to have Public 4over6 to handle this. And Public 4over6 is
matual enough to step forward without technical changes.

Best Regards!

Qi Sun


On 6/9/12, Reinaldo Penno <[e-mail]> wrote:
> Med,
>
> I'm glad we are in synch. That's exactly what I suggested Peng to do it.
> We can a single sentence in L46 to the effect:
>
> "If a full public IPv4 is given through DHCP no port set support is needed
> on CPE or concentrator. It is still up to the CPE if it wants to do NAT or
> not". Many DC scenarios use 1:1 NAT.
>
> Even DS-Lite can support public servers by using full port range port
> forwarding and disabling NAT.
>
> Thanks,
>
> Reinaldo
>
> On 6/7/12 10:58 PM, "[e-mail]"
> <[e-mail]> wrote:
>
>>Hi Peng,
>>
>>I vote for having one single document which covers both shared and full
>>IPv4 address.
>>
>>If you start for instance from draft-cui-softwire-b4-translated-ds-lite,
>>what is needed is to add one sentence to say a full IPv4 address can be
>>provisioned. Does this make draft-cui-softwire-b4-translated-ds-lite more
>>complex? I don't think so.
>>
>>I really think we need all to do an effort of rationalizing the solutions
>>space.
>>
>>Cheers,
>>Med
>>
>>>-----Message d'origine-----
>>>De : Peng Wu [mailto:[e-mail]]
>>>Envoyé : jeudi 7 juin 2012 18:31
>>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>Cc : Yong Cui; [e-mail]
>>>Objet : Re: [Softwires] WG last call on
>>>draft-ietf-softwire-public-4over6-01
>>>
>>>Med,
>>>
>>>From protocol level, the difference between public 4over6 and
>>>lightweight 4over6(b4-translated-ds-lite) lies in port-set support.
>>>The extra efforts of lw 4over6 are as follows: (1) port set support in
>>>DHCP provisioning; (2) NAT on the initiator side.(whose address pool
>>>is not a full address but only a port set)  (3) port-set supporting in
>>>the cocentrator's binding table.
>>>
>>>While we may cover public 4over6 by lightweight 4over6 with a special
>>>port set format (2^16 size) for (3), (1) and (2) brings quite
>>>significant changes to the intiator side. If I'm only a pb 4over6
>>>initiator, more typically a host initiator, all the complexity needed
>>>is to plant a CRA process on the host, which is basically an IPv4 &
>>>IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already
>>>there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is
>>>already supported in today's OS. No NAT is needed in host case, and
>>>full e2e transparency is guaranteed. If we support this by lw 4over6,
>>>we implemented extra complexity which is not needed at all by the
>>>initiator.
>>>
>>>We have deployement scenarios which probably don't require address
>>>sharing, such as CERNET, and I guess maybe the ISPs in USA also do not
>>>have an IPv4 address shortage problem?
>>>
>>>So, aside from the fact that the pb 4over6 draft starts earlier and
>>>its status has been a step furher, this is a problem of choice: do we
>>>want two clean, simple mechanisms, or one mechanism trying to be
>>>compatible with both.
>>>
>>>On Thu, Jun 7, 2012 at 9:11 PM,  <[e-mail]> wrote:
>>>> Dear all,
>>>>
>>>> I agree with Reinaldo.
>>>>
>>>> IMHO it makes sense to merge the two documents: either
>>>draft-ietf-softwire-public-4over6 be extended to cover
>>>draft-cui-softwire-b4-translated-ds-lite or add one or two
>>>sentences to draft-cui-softwire-b4-translated-ds-lite to
>>>mention a non-shared IPv4 address may be assigned.
>>>>
>>>> Doing so would help to rationalize the solution space and
>>>associated documents. We have the following main flavours:
>>>>
>>>> (1) Full stateful mode: DS-Lite
>>>> (2) Full stateless mode: MAP
>>>> (3) Per-customer state/binding mode: lw4o6
>>>(draft-cui-softwire-b4-translated-ds-lite)
>>>>
>>>> All the three modes must support the ability to assign a
>>>full IPv4 address.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>>-----Message d'origine-----
>>>>>De : [e-mail]
>>>>>[mailto:[e-mail]] De la part de Reinaldo Penno
>>>>>Envoyé : lundi 28 mai 2012 07:53
>>>>>À : Sheng Jiang; Yong Cui; [e-mail]
>>>>>Objet : Re: [Softwires] WG last call on
>>>>>draft-ietf-softwire-public-4over6-01
>>>>>
>>>>>-1
>>>>>
>>>>>In which significant way this document is different from
>>>>>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-
>>>>>lite-06 ?
>>>>>
>>>>>We can insert one paragraph in the above draft and allow
>>>>>public IPs since
>>>>>NAT is optional. The two documents even use DHCPv4ov6 as
>>>provisioning.
>>>>>
>>>>>
>>>>>
>>>>>On 5/27/12 6:32 PM, "Sheng Jiang" <[e-mail]> wrote:
>>>>>
>>>>>>The document looks mature for being advanced.
>>>>>>
>>>>>>Sheng Jiang
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [e-mail]
>>>>>[mailto:[e-mail]] On
>>>>>>> Behalf Of Yong Cui
>>>>>>> Sent: Sunday, May 27, 2012 10:31 PM
>>>>>>> To: [e-mail]
>>>>>>> Cc: Yong Cui
>>>>>>> Subject: [Softwires] WG last call on
>>>>>draft-ietf-softwire-public-4over6-
>>>>>>> 01
>>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> This is a wg last call on draft-ietf-softwire-public-4over6-01.
>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/
>>>>>>>
>>>>>>> As usual, please send editorial comments to the authors and
>>>>>>> substantive comments to the mailing list.
>>>>>>>
>>>>>>> This wg last call will end on 2012 June 10 at 12pm EDT.
>>>>>>>
>>>>>>>
>>>>>>> Yong & Alain
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Softwires mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>>>_______________________________________________
>>>>>>Softwires mailing list
>>>>>>[e-mail]
>>>>>>https://www.ietf.org/mailman/listinfo/softwires
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Softwires mailing list
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/softwires
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>_______________________________________________
>>Softwires mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/softwires
>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>