Dear authors,
I volunteered yesterday at the Softwires IETF 82 meeting to be one of
the reviewers of your draft. I reviewed it and I am sending the link
to the PDF which includes all the proposed changes and my comments. I
also tried to address some typos and grammar mistakes, but I since I
am
Dear Simon,
Is there anything worth arguing about this?
No, if violating RFC 6145 in such conditions is acceptable, there is
nothing worth arguing about this. I am new here, so I just don't know.
Thanks for your clarifications, it's just that I would like to understand
all these details in
Dear Cameron,
Thanks for your effort.
Easy math version assuming the entire internet moves to this model of
stateless address sharing:
50 Billion Internet nodes [1]
As I said, I don't think we should consider Internet of things in this
aspect. Quoting the paper:
As an example of connected
Dear authors,
I have some comments on your draft.
---
3. Terminology
snip
4rd IID prefix: A 32-bit value use to disambiguate what
concerns the 4rd address mapping from other
Dear Wojciech,
- If one believes that port unrestriced TCP provides enough security,
then the port-restriction does little to alter that in consideration of
host/CPE practices (no randomization). As you point out, such belief
may be misplaced, especially with larger widow sizes. Granted, a
Dear Simon,
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 like stateful
firewalls, IPS/IDS
Dear Brian,
Ahah, you seem to assume that A+P will solve the ISP's shortage
of IPv4 addresses. That may be true for a year or three, but
after that they will discover that they have to CGN their A+P
customers, and then you have NAT444 after all, IMHO.
I don't assume A+P an ultimate solution
Dear Cameron,
some pressure. IMHO, i believe that static over-subscription ratios
required by A+P will not meaningfully keep pace with the rapid growth
in the number of internet nodes.
I would be very happy if you elaborated on this. Can you give something
to support this belief?
Thanks,
Sure. The question is really whether its market share would be
enough to justify the effort.
But how can you know what the market share is? I mean, it's a
trade-off between having a smaller sharing ratio and having better
end-to-end (perhaps), direct CPE-CPE communication ... I say let's
give
Dear Brian,
won't work. But in my world, A+P-enabled hosts are connected to the
IPv6 network directly.
And how will that support legacy SOHO LANs?
It will not, because I don't have a legacy SOHO LAN. If I have legacy
SOHO LAN, I can use (optional) NAT44.
Nejc
Dear Gang,
What if in my deployment scenario there are no legacy end hosts? What
if all hosts implement A+P-style port ranges?
I'm with Nejc here. A+P/4rd/... do not require NAT44.
And then, how many hosts could support what if in the wild
I don't see why this is important. Anyway, the
Dear Gang,
NOT PRACTICABLE has two meanings.
1) Restricted port aware host is relatively few case
Since we are not developing mechanisms for the period of the next few
months, I don't think this argument is relevant. Long term, there
might (hopefully) be more such hosts.
2) Socket need to
Dear Rémi,
Whether Encapsulation and Double-translation methods will remain in separate
drafts or might be regrouped in a single one including their comparison is, as
far as I am concerned, an open question (neither in favor nor against).
Not being in favor of a wide palette of different
It will not, because I don't have a legacy SOHO LAN. If I have legacy
SOHO LAN, I can use (optional) NAT44.
Exactly, resulting in NAT444 . But if I'm forced to use NAT444
via a 4 in 6 tunnel anyway, A+P is pointless.
I don't think you understood what I was saying. There is no need for
Because of what RFC6333 says, suggesting NOW that solutions that don't need
NATs are variants of DS-lite is a sure way to confuse people.
+1
Nejc
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Dear Satoru,
We assume that all applications/OSes doesn't aware port restricted
environment.
Sure.
However, there is a case where an application would be allocated a port which
is inside of port set occasionally.
Yes. But I am just talking about being open to applications/OSes which
Dear Behcet,
A+P is the same case if I understand correctly. NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.
It _is_ fundamental, however it is not mandatory in all scenarios. Please
see draft-ymbk-aplusp-10 (which defines A+P
Dear Gang,
That is not practicable. You can't do such modification on innumerable hosts.
Who says only innumerable hosts will want to have this? My view on this is,
that these proposals are not meant to solve only a specific
problem for a specific scenario. Why would we want that? If we do
Dear Wojciech,
It's useful to note that the implementation of any A+P based scheme on
an end host has practical challenges, irrespective of what drafts say
(just think of two such host on the same LAN - something that is not
allowed)
Are these challenges documented anywhere? Also, why
Dear Naoki,
However, in my honest opinion, I am confused a little about target
technology in softwire.
Well, me too. This is why I am trying very hard lately to understand
things first.
SA46T and SA46T-AS is just a tunneling technology.
The other side, in my understanding, DS-Lite and
Dear authors,
as far as I can understand your draft, you make NAPT44 in the CE obligatory.
However, this is not the case for 4rd, dIVI, SA46T-AS and Lightweight
4over6 A+P
drafts. So I suggest that you make it optional in 4via6 translation as
well, since it might
be desired for some
Dear Gang,
as far as I can understand your draft, you make NAPT44 in the CE obligatory.
[Gang] Yes. This is to avoid the problem where there are applications
that attempt
to bind to specific ports that are not part of the allowed port range.
Well, if the application/operating system
a real life meeting to hash out the stateless solutions is a splendid idea.
But an expensive one too!
Since the announced deadline for practical organization has already been
passed, I personally believe that a better approach is to get enough Softwire
time in Taipei for enough WG work.
+1
Dear Rémi,
Maybe it would be better to only cover specifications for which drafts are
available.
(I found the two DSlite? columns confusing, with no document to check their
validity.)
I considered this, but then decided to do it this way since as far as I
understand, DS-Lite RFC doesn't
Hello,
I have some comments on your draft, see inline.
Regards,
Nejc
---
2. Terminology
This document makes use of the following terms:
Stateful 4/6 solution (or stateful solution in short): denotes a
solution where the network maintains
Dear Med,
[NS: If we consider a stateful A+P solution, we don't necessarily
have a dependency between an IPv6 prefix and IPv4 address. Also, we
don't have any user-session state in the Service Provider's network.
Med: Fully agree. FWIW, this is what we called Binding Table A+P Mode in
Dear Naoki,
Number of ports can be selected by prefix length.
I see.
So essentially, SA46T-AS is like 4rd, but with a different port-allocation
scheme. Also the IPv4 plane feature (you also call it IPv4 VPN service)
can be seen as a variant of multiple 4rd domains in 4rd context.
Do you
Dear Wojciech,
your comparison does not appear to include:
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
Interesting. I guess the idea is the same as in draft-xli-behave-divi-03? Could
you please elaborate a bit on the differences?
Also, feel free to use/refer to the
Dear Naoki,
1. Since we are analyzing IPv4 address sharing mechanisms in general (mostly
4over6 mechanisms), we are interested in the variant of your design, which
also includes a NAT somewhere in the network. As far as I understand, the
only plance where you can put a NAT device is the
Dear Reinaldo,
This could be a separate table. The good thing about this table is that is
clean and focused.
I don't think that extending this table on another page will make it less
clean and focused.
Nejc
___
Softwires mailing list
Hello all,
I am working on a trade-off analysis of IPv4 address sharing mechanisms. I am
replying to Remi's e-mail (sent before I subscribed to the list):
I therefore worked out a way to present the range of solutions to be
compared,
with the following taken in consideration:
- The
31 matches
Mail list logo
