Le 2014-03-05 14:29, Ian Farrer a écrit :
If the longest prefix match returns more than one matching prefix, then an
implementation specific tie-breaker MUST be performed to return a single
prefix.
Does this mean that the lwB4 and lwAFTR would need to be from the same
vendor?
Simon
--
DTN
,
Ian
On 5 Mar 2014, at 14:34, Simon Perreault simon.perrea...@viagenie.ca wrote:
Le 2014-03-05 14:29, Ian Farrer a écrit :
If the longest prefix match returns more than one matching prefix, then an
implementation specific tie-breaker MUST be performed to return a single
prefix.
Does
Le 2014-03-03 14:52, Wojciech Dec a écrit :
Lightweight 4over6 provides a solution for a hub-and-spoke softwire
architecture only,
where the AFTR maintains (softwire) state for each subscriber. A means for
optmizing the amount of such state using IPv4-IPv6 address mapping rules, as
well
Le 2014-02-16 14:39, Cong Liu a écrit :
We submitted a new draft about an issue on IPv4 communication between
two Softwire CEs with the same IPv4 addr and different port set.
Any comments are appreciate.
Here's the translation of this draft's recommendation into
implementer-speak:
- Do not
This part is still not OK:
5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour
On receiving an encapsulated packet containing an IPv4 fragment, the
lwB4 SHOULD wait until all other fragments have been received and de-
capsulated. The original packet is then re-assembled
Le 2014-02-07 11:01, ian.far...@telekom.de a écrit :
This part is still not OK:
5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour
On receiving an encapsulated packet containing an IPv4 fragment, the
lwB4 SHOULD wait until all other fragments have been received and de-
Le 2014-01-21 04:19, ian.far...@telekom.de a écrit :
1. Section 5.1:
An IPv6 address from an assigned prefix is also required for the lwB4
to use as the encapsulation source address for the softwire. In
order to enable end-to-end provisioning, the IPv6 address is
constructed
Le 2014-01-21 10:25, ian.far...@telekom.de a écrit :
[ian] The current text describes how the CPE creates the /128 prefix to
use as its tunnel endpoint (when its provisioned with DHCPv6). This prefix
has been constructed using an existing /64 prefix and a suffix that has
been learnt through the
Le 2014-01-16 02:19, Mikael Abrahamsson a écrit :
The fragmentation handling needs more guidance. 5.2.1. says:
On receiving an encapsulated packet containing an IPv4 fragment, the
lwB4 MUST wait until all other fragments have been received and de-
capsulated.
What happens if one of the
Le 2014-01-02 12:11, Ole Troan a écrit :
1. The distinction between BMR and FMR is very confusing. And it's going to get even more confusing when the
reader gets to draft-ietf-softwire-map-dhcp, where there is only a single unified rule parameter.
Suggestion: remove the concept of FMR. The
Le 2013-12-10 09:57, Simon Perreault a écrit :
I'll resend my WGLC comments right away.
Done:
Dec 10 09:58:14 jazz postfix/smtpd[14691]: BD259400A8:
client=unknown[2620:0:230:c000:54e0:da70:48b1:eece], sasl_method=PLAIN,
sasl_username=simon
Dec 10 09:58:14 jazz postfix/cleanup[14636
Le 2013-11-22 05:30, Wojciech Dec a écrit :
Consider the case where a MAP deployment has a need (for whatever
reason) to direct some CPEs to an AFTR (stateful NAT). Instead of
rolling out Ds-lite DHCP extensions all over
...or only to the CPEs in question...
it is trivially simple to
achieve
WG,
draft-ietf-softwire-map-08 contains this:
7.3. Backwards compatibility
A MAP-E CE provisioned with only the IPv6 address of the BR, and with
no IPv4 address and port range configured by other means, MUST
disable its NAT44 functionality. This characteristic makes a MAP CE
Le 2013-11-15 04:24, Ole Troan a écrit :
if optional, we have to think through the corner cases:
- how does a CPE know when to initiate DHCPv4 (or PCP)?
I would propose: when OPTION_S46_IPV4ADDRESS is absent.
DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We
don't need to
Le 2013-11-15 07:35, ian.far...@telekom.de a écrit :
If you are implementing OPTION_S46_CONT_LW46, I say you have to implement
all of the sub-options necessary to provision it, including
OPTION_S46_IPV4ADDRESS.
If you want to use DHCPV4oDHCPv6 or PCP, then you don’t have to implement
Le 2013-11-15 08:55, Ole Troan a écrit :
Cong,
DHCPv4/PCP enable options will be outside containers, because containers
contains sub-options.
I don't think that will work.
DHCPv6 server sends two containers MAP_E and LW46.
the client must be able to associate the enable options to one of
Le 2013-11-14 22:53, Ted Lemon a écrit :
Removing unneeded cruft is probably good too. I mean, if nobody is going to use
it...
How sure are you that nobody is going to use it? Serious question.
IMHO, if nobody comes to the WG with a need for it, then we should
remove it. If anyone comes
Le 2013-11-15 09:01, Ole Troan a écrit :
if optional, we have to think through the corner cases:
- how does a CPE know when to initiate DHCPv4 (or PCP)?
I would propose: when OPTION_S46_IPV4ADDRESS is absent.
DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We don't need
to
Le 2013-11-15 13:55, Ted Lemon a écrit :
On Nov 15, 2013, at 8:59 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
Right. I think that the utility of enable options still needs to be
demonstrated.
Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, not a
softwires
WG,
Currently draft-ietf-softwire-map-dhcp-05 says that
OPTION_S46_IPV4ADDRESS is mandatory. It has to be made at least optional
so that DHCPv4oDHCPv6 or PCP can be used for IPv4 address provisioning.
Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result
would be that
Le 2013-10-18 09:47, Tom Taylor a écrit :
Nothing seems to be happening to the work on the universal CPE draft
For everyone's information: there were *a lot* of private discussions
between the various draft authors. draft-ietf-softwire-map-dhcp-05 is
one immediate result. The other result is
...@huawei.com, Simon Perreault simon.perrea...@viagenie.ca
A new version of I-D, draft-perreault-softwire-lw4over6-pcp-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.
Filename:draft-perreault-softwire-lw4over6-pcp
Revision:00
Title: Provisioning
Le 2013-04-26 09:22, Ole Troan a écrit :
Cameron,
My concern is at the rogue MAP CE. Thus, the spoof protection
filtering should be applied at the attachment PE so that the rogue MAP
CE attempts at spoofing can squashed at the provider edge.
Make sense?
yes, that was what I meant too
Le 2013-04-26 16:50, Rajiv Asati (rajiva) a écrit :
Thankfully, in MAP, both CE and BR employ the so called port-range aware
uRPF, as Ole well clarified. So, the possibility of any device causing any
grief to any other device (in the network - CE or outside the network -
via BR) just does NOT
Le 2013-04-10 09:23, Rémi Després a écrit :
In my understanding, this justifies that an IPR statement that doesn't concern
an RFC (with due understanding of initiators of the statement), should be
deleted by its initiators, in good faith, rather than inappropriately listed in
the RFC itself.
Le 2013-04-10 07:15, Suresh Krishnan a écrit :
Any RFC listed in an ipr disclosure will have a notice added (described
in Section 5 of RFC3979) that will contain a disclaimer of validity.
According to that section, the notice will be added to any IETF RFC,
whether there is any IPR declaration
Le 2013-02-05 09:55, olaf.bonn...@telekom.de a écrit :
I see a useful work here that brings together the different Softwire
approaches under a unified CPE and would that's why vote for an
adoption as WG working item.
+1
Simon
___
Softwires mailing
Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit :
As agreed in Atlanta, we prepared an I-D describing a proposed approach for the
unified CPE.
We hope this version is a good starting point to have fruitful discussion.
Your comments, suggestions and contributions are more than
Le 2012-11-30 14:09, mohamed.boucad...@orange.com a écrit :
- Didn't we also consider public 4o6 as one mode? Any reason
why it was
left out?
- Is public 4o6 the minor change to lw4o6 that section
4.1 hints at?
Med: The rationale we adopted in this draft is as follows:
* there are three
Le 2012-11-30 14:22, ian.far...@telekom.de a écrit :
Ian: I broadly agree with what you've said, but one use case that did
cross my mind is if you only needed to provision mesh routes to a client
with no need for a concentrator/default route. A closed machine-to-machine
type service could be an
Le 2012-11-30 15:18, mohamed.boucad...@orange.com a écrit :
MAP-E:
- Lw4o6 set of provisioning information
- Forwarding mapping rules
Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional
parameters are needed for MAP. This is why the table included two entries for
Le 2012-08-24 11:39, Wojciech Dec a écrit :
Here's an idea: a restricted profile of MAP-E that would only
allow hub-and-spoke, described in a separate RFC, would look exactly
like LW4o6, right? And it could be implemented stand-alone, without
all the mesh code. And it could be
We're in Plaza C waiting for implementers. Are we in the right place?
Simon
Le 2012-07-30 12:35, Wojciech Dec a écrit :
Hi All,
small update: After an on0site visit it's been determined that we'll
relocate the MAP interop to room Plaza-C
Regards,
Woj.
On 29 July 2012 11:38, Wojciech Dec
On 07/10/2012 05:46 AM, Rémi Després wrote:
This draft contains valuable advices which can apply to 4rd as well as to
MAP-T+E, but is exclusively MAP oriented.
As such, I find it premature to move it to WG-draft status.
If 4rd is chosen for standardization, adapting this deployment draft to it
On 2012-06-26 04:50, Wojciech Dec wrote:
- A parameter PER DOMAIN was an obvious result of a merger.
- But a parameter PER RULE is a significant novelty.
OK?
That was not intended, and appears to be a genuine mistake in draft-00.
Thanks for spotting.
It is a parameter per domain, as
On 2012-06-07 08:51, mohamed.boucad...@orange.com wrote:
Among the use cases
of high priority identified in
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6,
the IGMP/MLD IWF is only required for the use case described in
draft-ietf-softwire-dslite-multicast.
The
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite
multicast would be better served by referencing our
On 2012-05-27 10:34, Yong Cui wrote:
This is a wg last call on draft-ietf-softwire-dslite-multicast-02.
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is in
draft-perreault-mboned-igmp-mld-translation. I
On 2012-05-22 12:29, Maoke wrote:
1. it is not the time to compare 4rd with MAP-T or with MAP-E
separately, but with the MAP-suite. i never think MAP-T is intended
to be the *unique* standard in the scope of residual deployment. (maybe
it was but we'd better discuss things based on current
.
Answering NO to this question means you want to see both advance on the
standard track.
Simon Perreault, Viagénie, YES (*)
(*) That's assuming we can reach a consensus. Otherwise both as
experimental sounds like the obvious way out.
Questions 2: Which one do you want to see placed
On 03/28/12 00:42, Tetsuya Murakami wrote:
Also, as I mentioned during the meeting, I double-checked the current
implementation of IPv6 stack (Linux/BSD). If implementing 4rd-u, IPv6
stack gives received IPv6 packet to 4rd-u module after processing it.
But, according to the current
On 03/28/12 09:22, Tetsuya Murakami wrote:
In terms of CNP, CNP needs to be calculated every time if the packet
is toward to outside of domain because the embedded IPv4 address
could be different. So, I think there is no difference between CNP
and recalculation of L4 checksum from the
On 03/28/12 12:28, Ole Trøan wrote:
There's a reason NPTv6 and NAT64 chose checksum neutrality...
NAT64??
Yup. RFC 6052 section 4.
Simon
--
DTN made easy, lean, and smart -- http://postellation.viagenie.ca
NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca
STUN/TURN server
On 03/28/12 12:43, Ole Trøan wrote:
There's a reason NPTv6 and NAT64 chose checksum neutrality...
NAT64??
Yup. RFC 6052 section 4.
as in We considered reserving 16
bits in the suffix to guarantee checksum neutrality, but declined
No, as in:
- The well-known prefix is intentionally
On 03/28/12 12:50, Maoke wrote:
Yup. RFC 6052 section 4.
do you mean the following paragraph:
No. See my response to Ole.
1. as a stateless address mapping, RFC6052 doesn't assumes any stateful
NAT64 is also required to use checksum-neutral address -- liberal to others
Not sure what
On 03/28/12 13:21, Tetsuya Murakami wrote:
Depends how you implement it. I can think of at least one way to do
it on Linux without touching the IPv6 stack. (with NF hooks)
Yes. It could be possible. But NAT44 requires a network device. If
NAT44 is also utilized, a 4rd-u module attached to IPv6
On 2012-03-06 13:03, Rémi Després wrote:
In this analysis, the 4rd-u port-set algorithm is presented as an instance of
GMA algorithm (i.e. Generalized Modulus Algorithm).
I think it would be more appropriate to have it in its own category, e.g. that of
parameter-less algorithms (it has no
mohamed.boucad...@orange-ftgroup.com wrote, on 09/07/2011 03:28 AM:
What I have done is I clarified the text as follows:
o Complexity: Reflects the complexity level of understanding the
algorithm and the expected complexity to configure an
implementation.
A subjective
On 2011-08-24 05:29, Nejc Škoberne wrote:
Agree. I think transmitting packets with invalid TCP checksum field is
dangerous.
Stateful NAT is ubiquitous nowadays.
Simon? How was the conclusion, that the transport checksum does not
need to be modified, reached?
Look, this is a deployment
On 2011-08-24 06:21, Nejc Škoberne wrote:
Dear Simon,
A consequence is that the 4rd address
scheme does not need to care about checksum neutrality (contrary to e.g.
NAT64
and NAT66).
Sorry, but I don't understand this. Can you please paraphrase?
Please refer to:
Nejc Škoberne wrote, on 08/23/2011 07:00 PM:
Yes, we've been discussing this internally among co-authors of
draft-despres-softwire-4rd-addmapping. The conclusion was that the transport
checksum does not need to be modified.
OK. But this then means, that if there are any stateful devices
Mark Townsley wrote, on 08/21/2011 10:19 AM:
It takes me about 30 seconds to describe at a high-level what 4rd is to
someone
who already understands ds-lite by referring to it as a stateless version of
ds-lite. That's a good thing.
To someone who already understands 6rd:
4rd is to IPv4
On 2011-08-18 22:03, GangChen wrote:
2011/8/18, Simon Perreault simon.perrea...@viagenie.ca:
On 2011-08-18 09:59, GangChen wrote:
NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.
What if in my deployment scenario
, 2011, at 8:57 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
On 2011-08-19 05:19, Tetsuya Murakami wrote:
draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation
I think it might be good to combine these 2 drafts to create one unified
document for 4rd specification
On 2011-08-17 04:08, Ole Troan wrote:
it would be good to have at least 4 weeks notice for travel arrangements to
be made.
Not only would it be good, it is required.
http://www.ietf.org/iesg/statement/interim-meetings.html
If we are to meet on September 15-16, the meeting must be announced
mohamed.boucad...@orange-ftgroup.com wrote, on 08/16/2011 11:03 AM:
As for the content of the next iteration of the document, we have two options
so far:
(1) Put back some sections which have been removed in -02, add a new section
to discuss dynamic vs. static, handle the comments received
On 2011-08-11 07:01, xiaohong.d...@orange-ftgroup.com wrote:
But I don't understand will the figure be different with 'scattered'
port-set NAT? To my knowledge, it's something todo with app's
behaviours and NAT type(EIM in our test). Would you explain if I miss
something? Thanks
As it was
On 2011-08-03 16:44, Tetsuya Murakami wrote:
So the 900G figure is valid *in theory*, but *in practice* we're
stuck with a number of sessions roughly equal to the number of
external ports available on the NAT.
As I mentioned above, the number of NAT session can be greater than
the available
On 2011-08-04 11:01, Cameron Byrne wrote:
Yes, because these NATs are endpoint-dependent, which is forbidden by
the BEHAVE RFCs.
It is still very usefull and will be deployed regardless.
Right. But the IETF needs consistency in the advice it provides.
I understand you need to keep your
On 2011-08-03 09:32, Rémi Després wrote:
I think there is an important point missing from this discussion. It is
tricky but it has important practical consequences.
As I said, The 900G figure is valid, *as long as internal hosts reuse
the same source address+port for different destinations*.
Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
Thanks, a clarification has made to clear a confusion of restricted port
set/ranges and NAT session table limitation. Even if a CPE is allocated 256
ports, NAT session can be made over 900G sessions in theory. ('2^32'Full
32bits v4 address -
Simon Perreault wrote, on 08/02/2011 09:24 AM:
Satoru Matsushima wrote, on 08/01/2011 10:41 PM:
Thanks, a clarification has made to clear a confusion of restricted port
set/ranges and NAT session table limitation. Even if a CPE is allocated 256
ports, NAT session can be made over 900G sessions
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in port-set/range,
end
user can exhaust them.
The fact that most ISPs have been successfully operating with 65536 ports per
subscriber demonstrates that it is possible to statically
On 2010-04-16 05:04, Rémi Després wrote:
(The current scope is: - DS-lite only - Only port-control servers
that assign ports one by one.)
1. With the IPv4 address shortage, ISP NATs will be more and more
necessary not only in point-to-point configurations, DS-lite in
particular, but also in
64 matches
Mail list logo
