Re:

Re:

Re:

Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 95.25% |    40387 | smd <at> ab.use.net
 50.00% |    1 |  4.75% |     2012 | sra <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    42399 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

Re:

Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     2008 | Total
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     2008 | sra <at> hactrn.net

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     1955 | Total
--------+------+--------+----------+------------------------
100.00% |    1 |100.00% |     1955 | sra <at> hactrn.net

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

Fwd: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA

FYI.

kurtis -

Begin forwarded message:

> From: ietf-secretariat <at> ietf.org
> Date: den 17 september 2004 16.22.48 MET
> To: ietf-announce <at> ietf.org
> Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF 
> Meeting in Washington, DC, USA
>
> There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting
> in Washington, DC, USA:
>
> October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft 
> Submissions
>
> All initial Internet-Drafts (-00) must be submitted by Monday, October 
> 18 at 9:00 AM ET.
> As always, all initial submissions (-00) with a filename beginning 
> with "draft-ietf"
> must be approved by the appropriate WG Chair before they can be 
> processed or announced.
> WG Chair approval must be received by Monday, October 11 at 9:00 AM ET.
>
> October 25: Cutoff Date for Revised (i.e., -01 and higher) 
> Internet-Draft Submissions
>
> All revised Internet-Drafts (-01 and higher) must be submitted by 
> Monday, October 25
> at 9:00 AM ET.
>
> Initial and revised Internet-Drafts received after their respective 
> cutoff dates will not
> be made available in the Internet-Drafts directory or announced, and 
> will have to be
> resubmitted. Please do not wait until the last minute to submit. The 
> Secretariat will
> begin accepting Internet-Draft submissions starting Monday, November 
> 08 at 9:00 AM ET,
> but may not post or announce them until Monday, November 15.
>
> Thank you for your understanding and cooperation. If you have any 
> questions or concerns,
> then please send a message to internet-drafts <at> ietf.org.
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant 
> dates for the 61st IETF
> Meeting can be found at 
> http://www.ietf.org/meetings/cutoff_dates_61.html.
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>

On the use of multiple PA prefixes or a single PI prefix for IPv6 multihoming

Hi,

There has been discussions recently on the use of multiple
provider-dependent aggregatable (PA) prefixes instead of a single
provider-independent (PI) prefix as the proposed way to multihome in
IPv6.

It is widely known that the use of PA prefixes allows to preserve the
Internet routing tables, thanks to route aggregation.

There exists other advantages as well.

Here is a recent work that aims at evaluating the benefits yielded by
the proposed IPv6 multihoming method over traditional IPv4 multihoming,
in terms of resilience and traffic engineering possibilities. It is
available at :
  http://www.info.ucl.ac.be/people/delaunoi/diversity/index.html

SUMMARY:

This document shows that the use of multiple PA prefixes per sites not
only allows route aggregation but also can be used to reduce end-to-end
delay by leveraging the Internet path diversity.
It is shown that stubs that use multiple PA prefixes can exploit paths
that are otherwise unavailable. Thus, the use of multiple PA prefixes
increases the number of paths available, i.e. the Internet path
diversity. Simulations are used on various topologies to quantify the
path diversity benefits offered by the use of multiple PA prefixes.
The document shows that a dual-homed stub that uses multiple PA prefixes
has already a better Internet path diversity than any multihomed stub
that uses a single provider-independent (PI) prefix, whatever its number
of providers.

Next, it is shown that delays can be improved by leveraging this
Internet path diversity. The use of multiple PA prefixes increases the
number of paths available. Among the new paths, some of them offer
better delays. Simulations show that 60% of the paths can benefit from a
lower delay.

CONCLUSIONS:

These observations show that, from a performance point of view, IPv6
multihomed stubs get benefits from the use of multiple PA prefixes and
should use them instead of a single PI prefix as in IPv4 today.
This study thus strongly encourages the IETF to pursue the development
of IPv6 multihoming solutions relying on the use of multiple PA
prefixes.
The use of such prefixes reduces the size of the BGP routing tables, but
also provides lower delays, more diverse Internet paths, which in turn
yields to better possiblities to balance the traffic load and to support
quality of service.

Cedric

Re: Comments on threats and things-to-think about

Thanks for the comments Leif.

>  > draft-nordmark-multi6-threats-02.txt
> 
> 
> "The third class of applications..." Applications that rely on reverse
> lookups even beeing available are fundamentally broken and have been for
> some time (since the arrival of low-cost SOHO broadband in fact). IPv6
> multihoming imho should treat this class of applications the same way
> that the second class.

I suspect some folks want to avoid making things worse for this class,
even though it is insecure. I'll make the draft capture that there is
a range of opinions.

> "Finally, the fifth class..." The availability of ipsec (and similar 
> solutions) together with channel bindings allow protocols which in
> themselves are vulnerable to MITM-attacks to operate with a high level
> of confidentiality in the security of the identification of the peer.
> A typical example is the Remote Desktop Protocol (RDP) which when used
> with oportunistic ipsec works well if channel bindings are available.
> Channel bindings provide a link between the ip-layer identification
> and the application protocol identification. This is an important aspect
> of security in application protocols which must be preserved by a multi6
> solution.

I'll add this to the draft.

  Erik

> Apart from these comments my first read of this draft (especially some
> of the sections on identification spoofing attacks) read like an account
> of how to get into trouble with ssh tunneling - these things happens
> today all the time. This is not to say that there are solutions in this
> space because there isn't The lack of efficient key-management is
> the root of all evil to paraphrase Knuth.