2012/6/12, [email protected] <[email protected]>: > Re-, > > Please see inline. > > Cheers, > Med > > >>-----Message d'origine----- >>De : liu dapeng [mailto:[email protected]] >>Envoyé : mardi 12 juin 2012 11:49 >>À : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : [email protected] >>Objet : Re: [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >> Ok, then we can make this more clear in our document. >> >>"States still should be maintained in other equipments, > > Med: Why "should"? The NAT is not mandatory
=>Current candidate solutions told me the NAT44 is mandatory part i.e. "The NAPT MUST in turn be connected to a MAP aware forwarding function, that does encapsulation/ decapsulation or translation to IPv6." and even if port restriction is > needed, a host may just restrict its port to be within the range. => This part we had discussed yesterday. That is a step back for our discussion, since you have acknowledged that is a state. So, I > don't see a reason to change "may" to "should". => depending on above, I think it should change "may" to "should" > > e.g. customer >>premises equipment or host, in order to restrict IP address or >>port number >>information into the configured context except that a >>non-shared IPv4 address is >>assigned to a standalone host." > > Med: No need to elaborate what the state is about. You asked to add a > sentence to say a state may exist in the LAN side, I updated the text to > cover your comment: > > "States may still exist in other equipments such as customer premises > equipment." => We have already figured out what state is about, why not stated. If there is any flawed bug, I'm happy to fix it. But I can't accept push back without any reasonable justification. Regards, Dapeng > >> >> >>Best Regards, >>Dapeng Liu >> >>2012/6/12, [email protected] <[email protected]>: >>> Hi Dapeng, >>> >>> I can't add the port restriction because stateless IPv4/IPv6 >>solutions >>> (e.g., MAP, 4RD) support also the ability to assign a full >>IP address. >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : liu dapeng [mailto:[email protected]] >>>>Envoyé : mardi 12 juin 2012 09:14 >>>>À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>Cc : [email protected] >>>>Objet : Re: [Softwires] I-D Action: >>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>>Hi Med, >>>> >>>>Thanks for posting this new version but I guess it doesn't >>reflect all >>>>the discussion we had. I suggest to make following modifications. >>>> >>>>"States still should be maintained in other equipments, e.g. >> customer >>>>premises equipment or host, in order to restrict port >>numbers within a >>>>dedicated range." >>>> >>>>Please be undestood all the efforts are for precise expression >>>>for the readers. >>>> >>>>Thanks, >>>> >>>>Best Regards, >>>>Dapeng Liu >>>> >>>>2012/6/12, [email protected] >><[email protected]>: >>>>> Dear WG members, >>>>> >>>>> The new version includes the comments received during the >>WG LC (from >>>>> Dapeng). >>>>> >>>>> A diff is available here: >>>>> >>>>> >>>>http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateles >>> s-4v6-motivation-02 >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> >>>>>>-----Message d'origine----- >>>>>>De : [email protected] >>>>>>[mailto:[email protected]] De la part de >>>>>>[email protected] >>>>>>Envoyé : mardi 12 juin 2012 07:43 >>>>>>À : [email protected] >>>>>>Cc : [email protected] >>>>>>Objet : [Softwires] I-D Action: >>>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> >>>>>> >>>>>>A New Internet-Draft is available from the on-line >>>>>>Internet-Drafts directories. >>>>>> This draft is a work item of the Softwires Working Group of >>>>the IETF. >>>>>> >>>>>> Title : Motivations for Carrier-side >>>>>>Stateless IPv4 over IPv6 Migration Solutions >>>>>> Author(s) : Mohamed Boucadair >>>>>> Satoru Matsushima >>>>>> Yiu Lee >>>>>> Olaf Bonness >>>>>> Isabel Borges >>>>>> Gang Chen >>>>>> Filename : >>>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> Pages : 16 >>>>>> Date : 2012-06-11 >>>>>> >>>>>>Abstract: >>>>>> IPv4 service continuity is one of the most pressing >>problems that >>>>>> must be resolved by Service Providers during the IPv6 transition >>>>>> period - especially after the exhaustion of the public >>>>IPv4 address >>>>>> space. Current standardization effort that addresses >>IPv4 service >>>>>> continuity focuses on stateful mechanisms. This document >>>>elaborates >>>>>> on the motivations for the need to undertake a >>companion effort to >>>>>> specify stateless IPv4 over IPv6 approaches. >>>>>> >>>>>> >>>>>> >>>>>>The IETF datatracker status page for this draft is: >>>>>>https://datatracker.ietf.org/doc/draft-ietf-softwire-stateless- >>>>>>4v6-motivation >>>>>> >>>>>>There's also a htmlized version available at: >>>>>>http://tools.ietf.org/html/submission.filename }}-02 >>>>>> >>>>>>A diff from previous version is available at: >>>>>>http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateles >>>>>>s-4v6-motivation-02 >>>>>> >>>>>> >>>>>>Internet-Drafts are also available by anonymous FTP at: >>>>>>ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>>_______________________________________________ >>>>>>Softwires mailing list >>>>>>[email protected] >>>>>>https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >>>> >>>>-- >>>> >>>>------ >>>>Best Regards, >>>>Dapeng Liu >>>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >> -- ------ Best Regards, Dapeng Liu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
