publish both as
standard track.
Answering NO to this question means you want to see both advance on the
standard track.
Francis Dupont, representing myself, YES
In your previous mail you wrote:
Here are some questions about the demo and SD-NAT.
1. As I see, the bindings of v6 and v4+ports are deterministic and
pre-configured on the AFTR. Will it be of great cost if they are installed
using NETCONF which is mentioned in one of
In your previous mail you wrote:
This is an issue common to all stateless solutions, including deterministic
NAT with (anaycast) IPv4 address pool.
= +1!
In fact, it is an issue common to all solutions implying mandatory
filtering on transport fields (aka layer 4) including ports.
Regards
In your previous mail you wrote:
In this context, the important consideration is AFAIK that it is
completely acceptable to lose fragmented packets that, with bad
luck, happen to be routed via distinct BRs when there is a route
change. Frequent route changes would have many more severe
In your previous mail you wrote:
What was the use case for non-contigous port sets?
= cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt
A good port set definition algorithm must be reversible, easy to
implement, and should be able to define non-continuous or random port
In your previous mail you wrote:
A quick question: why is there a SD-CGN? Do you mean the second NAT at
AFTR used to reshape the out-of-range source port into the restricted port
range?
= there must be a SD-CGN which:
- filter from SD-CPE to the Internet packets checking the SD-CPE
The principle is good, details are not:
- only switched (giga) Ethernets were used (no wireless)
- the PCP should get double arrow
- all SD-B4s run a PCP/NAT-PMP/UPnP-GID-v1+v2 server
(in fact they have the same kind of softwares, the laptop just offers
more tools, 1 times larger
In your previous mail you wrote:
Today, if a user generates a packet using an illegal IPv4 source address,
what would we do? We could drop the packet silently by doing
source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should
drop the packet silently.
= it is a bit
In your previous mail you wrote:
Great. So ISC already has DHCPv4 over IPv6 implementation now.
= yes but it is experimental: we don't use the IANA assigned number
for CRA6ADDR for instance (as IANA will be involved later in the IETF
process) and there are some interesting technical problems
Durand with a 'd' (as sensible as Dupont with a 't' :-)!
Francis Dupont fdup...@isc.org
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
In your previous mail you wrote:
Med: Why you need an IPv4 address to run PCP? An implementation
example would be as follows:
* At bootstrap of the CPE, once an AFTR is discovered, use the Plain
IPv6 PCP mode and the new opcode and options defined in
In your previous mail you wrote:
Med: The PCP case has been demoed.
= My comment is about PCP without any extension.
In the second demonstration scenario, the CPE requested several sets
of noncontiguous ports (utilizing draft-tsou-pcp-natcoord-03 and
In your previous mail you wrote:
[Qiong] We also have implemented and demoed in IETF 81th. Please refer to
http://tools.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-04.txt in
Appendix section.
= same: my comment is about the base PCP for port range discovery.
Regards
In your previous mail you wrote:
1) - we would have to define the DHCP port option. Not difficult but
same amount of work as defining a new ICMP type.
= is it a joke? DHCP has an extension mechanism, not ICMP.
2) - with the ICMP message, the ISP can change the port range
without having to
In your previous mail you wrote:
I failed to see how Stateless DS-Lite is different from B4 translated
DS-lite. We need to first understand what sd-NAT is trying to solve, then
decide whether it is needed or not.
= I agree and IMHO they have the same issue: the per-CPE port range
is far
In your previous mail you wrote:
+1
Re-,
Please see inline.
(I cut here: too long and unreable with not-ASCII characters,
quoted-printable silly coding and long lines)
Regards
francis.dup...@fdupont.fr
___
Softwires mailing list
In your previous mail you wrote:
In your previous mail you wrote:
(*) Question 1: It is not clear in text if there is a second NAT
in the AFTR or not. Could you please confirm/infirm a second NAT
is present?
= there is one but:
- it translates
In your previous mail you wrote:
However, the draft seems give people impression there is only one NAT
at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is
responsible for decapsulation and IPv4 package validation. Did I miss
something?
= yes, the SD-CGN (the SD-AFTR with
In your previous mail you wrote:
= I leave the draft-penno-* unclear items to Reinaldo...
(note: 1- it should be not what we want as it makes CPEs trivial
to track, 2- it doesn't remove the mandatory check on source ports
in the from CPE to the Internet way)
Med: I
In your previous mail you wrote:
(*) Question 1: It is not clear in text if there is a second NAT
in the AFTR or not. Could you please confirm/infirm a second NAT
is present?
in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the
correct IPv4
In your previous mail you wrote:
(*) Question 1: It is not clear in text if there is a second NAT
in the AFTR or not. Could you please confirm/infirm a second NAT
is present?
= there is one but:
- it translates only port numbers following an algorithm
- the NAT is
In your previous mail you wrote:
(1) Either issue a WG LC, or
+1
francis.dup...@fdupont.fr
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
In your previous mail you wrote:
Thanks for the clarification. Too bad the vendor landscape (both AFTR
and B4) grossly ignore that normative requirement of RFC6333 and either
fragment the payload instead of the tunnel,
= there is a feature (not a bug as it is not incorrect) in some
NATs (NAT-PTs) are defined to translate TCP and UDP but usually can
translate the ICMP echo service as known as 'ping'. It is an (ab)use
of the ID field of ICMP echo/echo reply packets which is handled
the same way than the TCP/UDP source port.
So in the real world 'ping' works at the same place
In your previous mail you wrote:
I don't know if the following question has already been discussed, but I
haven't found information on the net.
= there is a least one generic RFC about tunneling with a lot of
good things for error handling.
Consider the following topology:
In your previous mail you wrote:
We have raised this point during the last call which has been
issued on version 03 of the draft and suggested to remove this
section from the draft since it is not normative and also because
this depends on the taste of each SP and their deployment
26 matches
Mail list logo
