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
Nejc,
we indeed need some wordsmithing on that part of the text, but the message
that it tries to convey looks unaffected:
- 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
Thanks for the comments, inline please.
On Tue, Aug 23, 2011 at 9:58 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Hi all,
In IETF-81, the chairs asked the authors of different drafts on multicast
sit together to discuss and compromise. So we did.
Here are some comments on
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 Brian,
Thank you and in line...
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
-Original Message-
From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
Sent: Sunday, August 21, 2011 3:21 PM
To: Tina TSOU
Cc: Rémi Després; softwires@ietf.org;
Tina,
The problem with static allocation is that it cannot adapt quickly to
subscriber demand.
Exactly; so it cannot optimise the number of ports in use.
What strikes me in this conversation is that all these solutions are a
tremendous amount of work to deal with legacy equipment, and I have
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
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
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast
solutions, e.g., potential collocation or reuse of functions? Do we need some
mapping or interaction table of the function elements or tunnels
hi,
On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
Hi all,
Some more comments on draft-qin-softwire-dslite-multicast-04.
#1
General comment: is there any consideration of interaction with unicast
solutions, e.g., potential collocation or reuse of functions? Do
hi,
On Wed, Aug 24, 2011 at 10:21 AM, Tina TSOU tina.tsou.zout...@huawei.comwrote:
...
#2
Section 6.2
Translation and encapsulation both uses the same mPrefix64 and uPrefix64,
so mB4 could not determine whether to de-capsulate the packets only based on
mPrefix64 and uPrefix64. Propose to
Hi all,
+1 support all of them to become WG draft.
Yuanchao Su
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
于 2011/8/23 23:43, Nejc Škoberne 写道:
Dear authors,
In I-D.dec-stateless-4v6-02 there is a table on page 11, which says that
IPv4 Header Checksum needs to be recalculated in stateless translation
IPv4 address sharing solutions. Does this mean that _only_ the IPv4 header
checksum should be
Hi, all
I support all of the 5 drafts as softwire WG documents.
Best Regards
Qian Wang
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
15 matches
Mail list logo
