on the Internet do forward such packets (violating the rule
mentioned above).
Fixing #2 actually requires making forwarding decision based on src
and dst (which is not happening now).
More data (sorry, shameless plug :))
https://ripe67.ripe.net/presentation
, the router need to check
*source* address while making forwarding decision.
It looks like it is not happening now but it might get changed by
[src, dst] based routing.
> On Thu, Nov 7, 2013 at 8:58 AM, Jen Linkova wrote:
>>
>> On Thu, Nov 7, 2013 at 5:45 PM, Fred Baker (fred) w
ck in 2011. Now
majority of such traffic is TCP to our services and, again, IID checks
shows that these packets are from hosts.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
shows that these packets are from hosts.
>
> Any specifc clues by vendor?
I decided not to put any names on the slides but I identified ~20
vendors (see slide #8 at
https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf )
P.S. One more reason for me to like EUI-64-based IID ;-))
nks to all reviewers!).
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
the
> document.
I'm not aware of any IPR.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
see sunset4 during their
> career.
Amen!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
/32...
> -Original Message-
> From: Matthieu Boutier [mailto:bout...@irif.fr]
> Sent: Thursday, July 27, 2017 11:41 AM
> To: Chris Bowers
> Cc: David Lamparter ; rtgwg@ietf.org; Anton Smirnov
> ; Jen Linkova
> Subject: Re: Persistent loops when mixing rtgwg-en
up WG of the IETF.
>
> Title : Enterprise Multihoming using Provider-Assigned
> Addresses without Network Prefix Translation: Requirements and Solution
> Authors : Fred Baker
> Chris Bowers
>
port and
explain why we are looking for lower-level solution.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ise environments, where vast
majority of devices do not even support rule 5.5 of default address
selection, not mentioning having multipath transports enabled.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
enominator. Multupath transport (if/when hosts in the network start
using it) would complement the solution described in the Section4.
Would it address your concern?
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ed to work in the scenario,
when the network has multiple CPEs, each one connected to different
ISPs.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
(thanks, Ron!).
The main change is adding the section 6.3 to discuss the multipath
transport as a potential solution.
Please let the authors know if you think that there is still room for
improvement.
Thanks!
--
SY, Jen Linkova aka Furry
___
rtgwg
you have
any suggestions it would be highly appreciated!
Thanks!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ch the a host on the Internet/reach a host on the Internet
All fixed.
> (18) [style nit/personal preference] Much of the text is written in first
> person ("In this document we assume that..."). I find the use of the third
> person ("In this document it is assumed that..." or "This document
> assumes...")
> more appropriate in IETF documents. Maybe just a manner of taste...
Well, I have not addressed this one - how strong do you feel about it?
Point taken for future drafts but I'm a bit reluctant (read: lazy) to
update this one...
Unless you really want me to..
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
//www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-enterprise-pa-multihoming-09
The full text:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09
Please let me know if you believe your comments have not been fully addressed!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
the draft concludes that
it's not a suitable mechanism anyway. The draft concludes that RAs
should be used (with some help of ICMPv6) and the discusses the
security aspect of the recommended approach (ICMPv6 + Neighbor
Discovery/RAs)
> A few editorial nits:
All fixed, thanks for pointing them out!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
s document defines a way for network/This document defines a way
> for
> networks/ or
> s/This document defines a way for network/This document defines a
> way
> for the network/
Fixed, thanks!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ection 5.2.3 also talks about a potential extension to ICMPv6 that
> would indicate what source address to use, in addition to noting that
> the selected source address does not work. Such an extension would also
> have some new security considerations, in that it would provide an
> attacker some measure of control over where the resulting traffic ended
> up, as (e.g.) might be useful in steering a DDoS.
I've added some text about
"However this approach has some security
implications such as an ability for an attacker to send spoofed
ICMPv6 messages to signal invalid/unreachable source prefix causing
DoS-type attack.
"
I think that if such messages are required to be sent from the
link-local address and the GTSM is enforced, then the attack vector is
limited to the same L2 domain which is a bit better..I'll add the text
to clarify it tomorrow.
Please let me know if I've missed/not address you comments (with the
exception of those two where I'd like to hear from my co-authors..).
Thanks!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
this draft/the aim of this document/ also in a couple of places.
All fixed.
> -- Section 4 --
>
> Please expand ULA before first use (+ reference)
I've actually added it to the Terminology section.
>
> -- Section 5 --
> s/host internal to the multi-homed site/host inside the multi-homed site/
Fixed.
>
> -- Section 5.1 --
>
> Please put all rules explanation in a separate paragraphs (esp rules 1 & 2).
Fixed.
>
> -- Section 5.5.2 --
>
> Please expand GUA before first use.
Added to the Terminology section.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
to the first mention of DHCPv6 in the doc.
>
> * Section 7.3
>
> I think a reference to something like RFC6824 might be useful here
Added.
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ons and upper-layer
protocols is selected with the up-to-date network state in mind.'
I guess it's close to what you are saying - that the solution we
propose would provide the multi-path protocols with the signal what
addresses could be used.
Or would you like to see more text on thi
solutions.
>
> Is that second sentence right? If you are giving a general class of solutions,
> that seems agnostic to the particular solution. Just a bit confusing.
Updated.
>
>A host SHOULD be able respond dynamically...
>
> Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.
Fixed, thanks!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ent from SERs (which are a few hops away).
I've moved all security considerations from that section to Section 10:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-10
Please let me know if you have any comments for -10 version.
Thanks!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
ch other so deploying multipath protocols in
PA-based multihomed network proves mutually beneficial".
Thanks for your suggestion!
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
nterprise-pa-multihoming-11#section-8.3
> >> My suspicion is that section 7.3 underestimates the availability
> >> (current and
> >> future) of multipath transport.
> You can have the half empty glass; I'll take the half full one. ;-)
As per Magnus's suggestion, I've updated the text to mention that
PA-based multihoming and MP transport could benefit from each other:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3
--
SY, Jen Linkova aka Furry
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
/doc/draft-llsyang-rtgwg-dst-src-routing/
--
SY, Jen Linkova on behalf of draft-llsyang-rtgwg-dst-src-routing-00 authors.
___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
, I see 'routing based on source IP' as not a solution but a
requirement for a number of use cases. Currently we are doing it using
ugly hacks like policy-based routing, it would be nice to find a
better solution.
> > On Jul 6, 2022, at 3:41 PM, Jen Linkova wrote:
> >
>
resented it last
week at the RTGWG session we asked for re-adoption.
>I can only be pleased by seeing this important piece (to my eyes) of work.
Thank you for the feedback!
> Hope this helps ‘the universal deployment of IPv6’ ;-)
Me too ;)
--
__
> rtgwg mailing list -- rtgwg@ietf.org
> To unsubscribe send an email to rtgwg-le...@ietf.org
--
Cheers, Jen Linkova
___
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
31 matches
Mail list logo
