Re: Question about REAP state transition (draft-ietf-shim6-failure-detection-09)

[Iljitsch van Beijnum <[e-mail]>]

Alberto,

it's been a long time, so I'm not entirely sure if I missed something  
else in your message. Please let me know if that's the case. I want to  
change this text:

<t hangText='Precvd'><vspace blankLines='1'/>

This is a 4-bit field that indicates the number of received probes
included in this probe message. Received probe fields are copies of the
same fields received in (recent) earlier probes and may be included or
omitted as per any logic employed by the implementation.


to:


<t hangText='Precvd'><vspace blankLines='1'/>

This is a 4-bit field that indicates the number of received probes
included in this probe message. Received probe fields are copies of the
same fields in earlier received probes that arrived since the last  
transition from state Operational to state Exploring. When a sender is  
in state InboundOk it MUST include copies of the fields of at least  
one the inbound probe. A sender MAY include additional sets of these  
received probe fields in any state as per any logic employed by the  
implementation.


I think this addresses the problem where two unidirectional paths  
wouldn't be found.





Envelope-to: [e-mail]
Delivery-date: Thu, 31 Jan 2008 12:13:31 +0000
Cc: <[e-mail]>
Message-Id: <[e-mail]>
From: Iljitsch van Beijnum <[e-mail]>
To: =?ISO-8859-1?Q?Alberto_Garc=EDa?= <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Question about REAP state transition   (draft-ietf-shim6-failure-detection-09)
Date: Thu, 31 Jan 2008 13:11:19 +0100

Alberto,

it's been a long time, so I'm not entirely sure if I missed something  
else in your message. Please let me know if that's the case. I want to  
change this text:

<t hangText='Precvd'><vspace blankLines='1'/>

This is a 4-bit field that indicates the number of received probes
included in this probe message. Received probe fields are copies of the
same fields received in (recent) earlier probes and may be included or
omitted as per any logic employed by the implementation.


to:


<t hangText='Precvd'><vspace blankLines='1'/>

This is a 4-bit field that indicates the number of received probes
included in this probe message. Received probe fields are copies of the
same fields in earlier received probes that arrived since the last  
transition from state Operational to state Exploring. When a sender is  
in state InboundOk it MUST include copies of the fields of at least  
one the inbound probe. A sender MAY include additional sets of these  
received probe fields in any state as per any logic employed by the  
implementation.


I think this addresses the problem where two unidirectional paths  
wouldn't be found.



Envelope-to: [e-mail]
Delivery-date: Sun, 27 Jan 2008 17:48:03 +0000
Cc: Geoff Huston <[e-mail]>, Brian E Carpenter <[e-mail]>, [e-mail], [e-mail], Iljitsch van Beijnum <[e-mail]>, Erik Nordmark <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
From: marcelo bagnulo braun <[e-mail]>
To: Jari Arkko <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set
Date: Sun, 27 Jan 2008 10:42:32 +0100

Done.

I have added the following paragraph to the end of section 1.6 =20
Placement of the shim

There are different types of interactions between the Shim6 layer and =20=

other
protocols. Those intereactions are influenced by the usage of the =20
addresses that
these other protocols do and the impact of the Shim6 mapping on these =20=

usages.
A detailed analysis of the interactions of different portocols, =20
including SCTP,
MIP and HIP can be found in <xref target=3D'I-D.ietf-shim6-=20
applicability'/>

Regards, marcelo


El 10/07/2007, a las 14:21, Jari Arkko escribi=F3:

> Geoff, Brian,
>
>>>>
>>>> I would like to propose that your comments are addressed in the
>>>> related current SHIM6 document activity on the topic of an
>>>> applicability statement, and, given that situation, there is no
>>>> compelling case to revise the protocol document to include this =20
>>>> (and
>>>> related) applicability considerations.
>>>
>>> However, the applicability draft is not cited in the proto draft.
>>> It's listed as a reference, but is not cited. That's going to
>>> have to be fixed editorially anyway. I agree that the applicability
>>> draft is the appropriate place to discuss this.
>>
>> ok - we'll do this editorially, as its not a normative issue
>
> I agree with Brian that needs to be mentioned at
> least indirectly. Adding a reference to the app note
> and a few words to explain the reference would be
> my preference.
>
> But lets not revise the document because of this.
> Once the ADs have the proto questionnaires in
> their hands, they will start AD review and eventually
> IETF Last Call and IESG review. A small edit can live
> as an RFC Editor note in the tracker until we've collected
> enough to warrant a new revision in one of the stages
> or until the document is shipped to the RFC Editor.
> Chairs, authors, can you suggest text for the new
> reference so that I can place it in the tracker?
>
> Jari
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 21:09:43 +0000
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Cc: shim6-wg <[e-mail]>
Reply-To: [e-mail]
Content-Transfer-Encoding: 7bit
From: Bob Hinden <[e-mail]>
Subject: Re: ICMP message for ingress filtering
Date: Mon, 7 Jan 2008 13:08:26 -0800
To: Iljitsch van Beijnum <[e-mail]>

Iljitsch,

> Hi shimmers,
>
> After a discussion about performing proxy shim operation and the  
> acceptability of NAT for that, it occurs to me that we never  
> actually solved the ingress filtering issue.
>
> When a host connects to ISPs A and B and then sends a packet with a  
> source address from ISP A's address range out to ISP B, it's likely  
> that ISP B will drop the packet because it has an "invalid" source  
> address. Solving this in the general case is non-trivial, but I  
> think it should be possible to get us most of the way there with a  
> fairly simple mechanism: a new "source address prohibited" ICMP  
> message. Just like when a host receives a "destination unreachable"  
> message it tries a different destination address, receiving a  
> "source address prohibited" message would make the host try a  
> different source address.

In the last update to ICMPv6 RFC4443, we added a Code to the  
Destination Unreachable ICMP error message:

         5 - Source address failed ingress/egress policy

    If the reason for the failure to deliver is that the packet with  
this
    source address is not allowed due to ingress or egress filtering
    policies, the Code field is set to 5.

A code for Reject Routes was also added.

The intent was to solve the problem as you described.  It, of course,  
doesn't help with ICMP(v4).

Bob


>
> Since this isn't a shim6- or even IPv6-specific issue (IPv4 hosts  
> can also have multiple addresses, it's just not all that common)  
> this would probably have to happen in the internet area working  
> group but I thought I'd ask for feedback from this wg first.
>
> The reason this came up in regard to shim6 proxying is that if a  
> host behind such a proxy has ULA addresses or another address type  
> with similar properties, it would be necessary to perform NAT to  
> communicate with legacy IPv6 destinations. If you give the host  
> behind the proxy regular PA addresses on the other hand, you are  
> still largely bound by the limitations of those addresses.  
> Alternatively, we could give a proxied host both ULA-like  
> identifier addresses for use towards shim6-capable destinations and  
> regular PA addresses for use towards legacy destinations. RFC 3484  
> address selection should help select the right source address here,  
> but this isn't fool proof. So in case the host selects the wrong  
> type of address, the proxy could send back a "source address  
> prohibited" ICMP message and the host would retry with a different  
> source address.
>
> It would be good to get this into host IPv6 stacks even if routers  
> won't support it immediately so that we can make use of this when  
> we create shim6 proxies.
>
> An ICMP message like this would also be useful for sites that would  
> like to use ULA addressing for their internal network but regular  
> addresses for connectivity to the internet.
>